Strange chars
-
I really, really would show the entire code because I am struggling of it, but unfortunately I cannot due to confidentiality issue. I'll try to write more code here.
-
What you need to display is the assignment to dir_struct.directory - nothing more. It may be as simple as a single statement (/line). I guess that confidentiality issues won't preclude that. How did you get hold of that value? Which system call or library function provided it? If you say "None, we built it from pieces ourselves, and that code is confidential", then you have got the answer: In that string building code you forgot to add the terminating nul. Otherwise: Tell us who provided the directory string, in which way.
No, this code is not written by us. I'll try to write here as much as I can. P.S. The buggy code is written in C for Linux, and I don't know C (I guess this is visible :D) P.S. I don't pretend to know C++ either :D ... only that I fight in this domain ....
-
I am sure that you can modify any confidential pieces so they do not reveal anything that they should not.
-
info* current = list_entry(walker, const info, list);
TRACE(_T("current->name %s\n"), current->name); -> _CrtDbgReport: String too long or IO ErrorWhy I got _CrtDbgReport: String too long or IO Error I wrote in my previous posts ...
I have managed to create a sample of all that code, although I find the
#define list_entry_constsomewhat difficult to deconstruct. However, with a valid name in thefile_infoentry it works fine. I can only assume that somewhere in the actual code that you are running there is some corruption of your data, or a pointer is not set up correctly. [edit] I also could not find the TRACE macro in Windows. [/edit] -
I really, really would show the entire code because I am struggling of it, but unfortunately I cannot due to confidentiality issue. I'll try to write more code here.
Like they say in the movies, the names have been changed to protect the innocent.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
I have managed to create a sample of all that code, although I find the
#define list_entry_constsomewhat difficult to deconstruct. However, with a valid name in thefile_infoentry it works fine. I can only assume that somewhere in the actual code that you are running there is some corruption of your data, or a pointer is not set up correctly. [edit] I also could not find the TRACE macro in Windows. [/edit]Richard MacCutchan wrote:
I also could not find the TRACE macro in Windows.
Isn't that an MFC thing?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Richard MacCutchan wrote:
I also could not find the TRACE macro in Windows.
Isn't that an MFC thing?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
I have managed to create a sample of all that code, although I find the
#define list_entry_constsomewhat difficult to deconstruct. However, with a valid name in thefile_infoentry it works fine. I can only assume that somewhere in the actual code that you are running there is some corruption of your data, or a pointer is not set up correctly. [edit] I also could not find the TRACE macro in Windows. [/edit]Richard MacCutchan wrote:
I also could not find the TRACE macro in Windows.
After a lot of calls... it finishes calling _CrtDbgReportW
-
Richard MacCutchan wrote:
I also could not find the TRACE macro in Windows.
After a lot of calls... it finishes calling _CrtDbgReportW
-
Like they say in the movies, the names have been changed to protect the innocent.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
#define DIR_NAME_LEN 2048
struct dir_struct
{
void* display;
char directory[DIR_NAME_LEN];
...
....I have followed the way of how this variable is handled:
dir_struct_t dir_struct;
TRACE(\_T("Directory - %s\\n"), dir\_struct.directory); -> \_CrtDbgReport: String too long or IO Error strncpy(dir\_struct->directory, "/", sizeof(dir\_struct->directory)); TRACE(\_T("Directory - %s\\n"), dir\_struct->directory); -> / strcat(dir\_struct->directory, current\_file->name); TRACE(\_T("Directory - %s\\n"), dir\_struct->directory); -> \_CrtDbgReport: String too long or IO ErrorAnd if I look into VS debugger when I got "_CrtDbgReport: String too long or IO Error" from TRACE macro, I see the following result: see image.[^] and Untitled2 — Postimage.org[^] The line
strcat(dir_struct->directory, current_file->name);is not quite correct ? I mean, correct for Windows, even if is correct for Linux ...I am really puzzled by how difficult it seem to be to explain how the value of that .directory was initialized. Where its value came from. How it was created. Obviously, whatever created the value did not follow the C convention of terminating it with a nul - most likely because it doesn't have a C origin. Fair enough. But why is it so difficult to show how the .directory value was obtained? As it now stands, it is like complaining "This variable should have av value between 0 and 100, but it is above 100. Why???" If you can't figure that out yourself, you must reveal how you calculate it, you cannot simply tell us how you use it, after it has gotten that out-of-range value- Your directory string is another out-of-range value. How you use it, after it got this illegal value is of no interest. The important thing is how it got that value, not how you later use it. Like if you ask "Why does my value exceed 100?" Noone can tell unless you tell how you got or calculated that value. String values are no different: If they have an illegal value, such as not being nul-terminated in contexts where that is expected, the problem is in the source, not in the use of the value. If it is as difficult as it seems to trace the source, identify where that directory sting came from, then you should not expect others to be able to help you. "I have an illegal value, but I can't tell where it came from - why is it not legal?" - noone can give you a reasonable answer to that. So come on, tell us how the .directory value was obtained/created! Until you do that, you cannot expect any useful help from other forum members
-
I am really puzzled by how difficult it seem to be to explain how the value of that .directory was initialized. Where its value came from. How it was created. Obviously, whatever created the value did not follow the C convention of terminating it with a nul - most likely because it doesn't have a C origin. Fair enough. But why is it so difficult to show how the .directory value was obtained? As it now stands, it is like complaining "This variable should have av value between 0 and 100, but it is above 100. Why???" If you can't figure that out yourself, you must reveal how you calculate it, you cannot simply tell us how you use it, after it has gotten that out-of-range value- Your directory string is another out-of-range value. How you use it, after it got this illegal value is of no interest. The important thing is how it got that value, not how you later use it. Like if you ask "Why does my value exceed 100?" Noone can tell unless you tell how you got or calculated that value. String values are no different: If they have an illegal value, such as not being nul-terminated in contexts where that is expected, the problem is in the source, not in the use of the value. If it is as difficult as it seems to trace the source, identify where that directory sting came from, then you should not expect others to be able to help you. "I have an illegal value, but I can't tell where it came from - why is it not legal?" - noone can give you a reasonable answer to that. So come on, tell us how the .directory value was obtained/created! Until you do that, you cannot expect any useful help from other forum members
-
I am really puzzled by how difficult it seem to be to explain how the value of that .directory was initialized. Where its value came from. How it was created. Obviously, whatever created the value did not follow the C convention of terminating it with a nul - most likely because it doesn't have a C origin. Fair enough. But why is it so difficult to show how the .directory value was obtained? As it now stands, it is like complaining "This variable should have av value between 0 and 100, but it is above 100. Why???" If you can't figure that out yourself, you must reveal how you calculate it, you cannot simply tell us how you use it, after it has gotten that out-of-range value- Your directory string is another out-of-range value. How you use it, after it got this illegal value is of no interest. The important thing is how it got that value, not how you later use it. Like if you ask "Why does my value exceed 100?" Noone can tell unless you tell how you got or calculated that value. String values are no different: If they have an illegal value, such as not being nul-terminated in contexts where that is expected, the problem is in the source, not in the use of the value. If it is as difficult as it seems to trace the source, identify where that directory sting came from, then you should not expect others to be able to help you. "I have an illegal value, but I can't tell where it came from - why is it not legal?" - noone can give you a reasonable answer to that. So come on, tell us how the .directory value was obtained/created! Until you do that, you cannot expect any useful help from other forum members
-
The AnotherFunction itself or the way you are using it seems to be a reason of your problem... :|
Yes Victor, you had right, from AnotherFunction is coming sometime a value like this: Oe©*Bº cE«Mòצ£š{@Q—Y|†Š˜ b! And this AnotherFunction is
list_entry_const()... is coming from Linux, and to reproduced in a test project is quite difficult ... Now I have to see where is the starting point for that strange chars ... -
Yes Victor, you had right, from AnotherFunction is coming sometime a value like this: Oe©*Bº cE«Mòצ£š{@Q—Y|†Š˜ b! And this AnotherFunction is
list_entry_const()... is coming from Linux, and to reproduced in a test project is quite difficult ... Now I have to see where is the starting point for that strange chars ...It looks like this function returns some local variable that goes out of scope after returning. However, better would be looking in its sorce code.
-
I am really puzzled by how difficult it seem to be to explain how the value of that .directory was initialized. Where its value came from. How it was created. Obviously, whatever created the value did not follow the C convention of terminating it with a nul - most likely because it doesn't have a C origin. Fair enough. But why is it so difficult to show how the .directory value was obtained? As it now stands, it is like complaining "This variable should have av value between 0 and 100, but it is above 100. Why???" If you can't figure that out yourself, you must reveal how you calculate it, you cannot simply tell us how you use it, after it has gotten that out-of-range value- Your directory string is another out-of-range value. How you use it, after it got this illegal value is of no interest. The important thing is how it got that value, not how you later use it. Like if you ask "Why does my value exceed 100?" Noone can tell unless you tell how you got or calculated that value. String values are no different: If they have an illegal value, such as not being nul-terminated in contexts where that is expected, the problem is in the source, not in the use of the value. If it is as difficult as it seems to trace the source, identify where that directory sting came from, then you should not expect others to be able to help you. "I have an illegal value, but I can't tell where it came from - why is it not legal?" - noone can give you a reasonable answer to that. So come on, tell us how the .directory value was obtained/created! Until you do that, you cannot expect any useful help from other forum members
Here is what I've discovered by now:
dir_data_t directory_data;
strncpy(directory_data.current_directory, "/", sizeof(directory_data.current_directory));directory_data is ok by now.
struct list_head* filewalker = NULL;
file_info_t dirlist;
logdir(&directory_data, &dirlist);
INIT_LIST_HEAD(&dirlist.list);
const file_info_t* current_file = NULL;
list_for_each(filewalker, &dirlist.list)
{
current_file = list_entry_const(filewalker, const file_info_t, list);
TRACE(_T("current_file->name %s\n"), current_file->name); // ->> now, sometime, current_file->name has a value like that: Oe©*Bº cE«Mòצ£š{@Q—Y|†Š˜ b! and from now one, everything goes bad
}after that,
strcat(directory_data.current_directory, current_file->name);
is not ok, of course.
INIT_LIST_HEAD,list_for_eachandlist_entry_constare Linux functions.logdirfunctions I could not reproduced in a test app or write here because has many dependencies ... and to be everything more complicated, all this code is written in a recursive function .... is quite difficult to reproduced this situation in a test app ... I am trying to explorelogdirfunction to see what I find there ... -
Here is what I've discovered by now:
dir_data_t directory_data;
strncpy(directory_data.current_directory, "/", sizeof(directory_data.current_directory));directory_data is ok by now.
struct list_head* filewalker = NULL;
file_info_t dirlist;
logdir(&directory_data, &dirlist);
INIT_LIST_HEAD(&dirlist.list);
const file_info_t* current_file = NULL;
list_for_each(filewalker, &dirlist.list)
{
current_file = list_entry_const(filewalker, const file_info_t, list);
TRACE(_T("current_file->name %s\n"), current_file->name); // ->> now, sometime, current_file->name has a value like that: Oe©*Bº cE«Mòצ£š{@Q—Y|†Š˜ b! and from now one, everything goes bad
}after that,
strcat(directory_data.current_directory, current_file->name);
is not ok, of course.
INIT_LIST_HEAD,list_for_eachandlist_entry_constare Linux functions.logdirfunctions I could not reproduced in a test app or write here because has many dependencies ... and to be everything more complicated, all this code is written in a recursive function .... is quite difficult to reproduced this situation in a test app ... I am trying to explorelogdirfunction to see what I find there ...