Printable View
Hello,
I have two programs which running both on solaris and windows. No problems on windows but on solaris one crashes. Generates a core file. I have two questions, what is this error message and how can I read the core file (starting with 0x127 and ELF).
Compilers do different things differently. When a windows
program crashes, you typically either get a window and then the
program is killed by the OS ... or you get a Blue Screen of Death.
On unix, the program terminates and you get a core dump. I'm
not sure how to read them, but why don't you try doing cout's
[while flushing!] to see where your program is crashing?
--Paul
Paul, thank you for the reply. Couts are exactly what I did and found that one of the very few platform specific parts, the opendir, readdir crashed with null pointer exception (directory does not exist, then read from the null directory).
Just red recently that somehow dbx or whatever can read those ELF files...
So what happens if the Windows version runs into directories that do not exist?Quote:
Originally posted by luftwaffe
Paul, thank you for the reply. Couts are exactly what I did and found that one of the very few platform specific parts, the opendir, readdir crashed with null pointer exception (directory does not exist, then read from the null directory).
Just red recently that somehow dbx or whatever can read those ELF files...
Regards,
Paul McKenzie
Maybe the best if I post the code snippets:
As you might have known already, the logic how windows and unix does it a bit different. Unix crashes on readdir and closedir if that is 0; windows simply return 0 (BOOL: FALSE) on FindFile/FindNextFile and if you close a search what was not open (Close()) then it does not crash (CFileFind freed when gets out of scope, hopfully :) ).
#ifndef WIN32
DIR *pDirectory;
struct dirent *pDirectoryEntry;
struct stat DirectoryStat;
pDirectory = opendir(TempStruct.VersionRootDir.c_str());
if (pDirectory != 0) {
while ((pDirectoryEntry = readdir(pDirectory))) {
// check if directory can be sequenced or not
if (stat(pDirectoryEntry->d_name, &DirectoryStat) == 0) {
if (DirectoryStat.st_mode & S_IFDIR) {
TempFile = fopen((TempStruct.VersionRootDir + pDirectoryEntry->d_name + CurrentSettings.PathSeparator + TempStruct.FileName).c_str(), "rb");
if (TempFile) {
fseek(TempFile, 0, SEEK_END);
if ((TempDateSize.Size = ftell(TempFile)) > -1) {
TempDateSize.Creation = pDirectoryEntry->d_name;
TempStruct.DateAndSize.insert(TempStruct.DateAndSize.end(), TempDateSize);
TempStruct.CurrentSizeOfVersionedFileKb += TempDateSize.Size;
}
fclose(TempFile);
}
}
}
}
closedir(pDirectory);
}
#else
CFileFind FindDirectories;
BOOL FoundFiles = FindDirectories.FindFile((TempStruct.VersionRootDir + "*.*").c_str());
while (FoundFiles) {
FoundFiles = FindDirectories.FindNextFile();
if (FindDirectories.IsDirectory()) {
CString FileName;
FileName.Format("%s%s%c%s", TempStruct.VersionRootDir.c_str(), FindDirectories.GetFileName(), CurrentSettings.PathSeparator, TempStruct.FileName.c_str());
TempFile = fopen(FileName, "rb");
if (TempFile) {
fseek(TempFile, 0, SEEK_END);
if ((TempDateSize.Size = ftell(TempFile)) > -1) {
TempDateSize.Creation = FindDirectories.GetFileName();
TempStruct.DateAndSize.insert(TempStruct.DateAndSize.end(), TempDateSize);
TempStruct.CurrentSizeOfVersionedFileKb += TempDateSize.Size;
}
fclose(TempFile);
}
}
}
FindDirectories.Close();
#endif
Ok your asking me to reach real far back to the UN*X world, but use the debuggers, adb or dbg on UNI*X which like I said killed those brain cells long ago, any hoo, look at the man pages for the usage... You essentially want to open the core file thru the debugger, and type the command .where or where to get the stack...
Windoze...dont' know if you know, or if you do well you do, but it's called a Bug Check, or system stop. If you want some good info on decoding them, then the help from windbg will at least give you an overview, quite frankly I got tired of .reboot along time ago :) :) :) But then I was the one causing them :)Quote:
Originally posted by PaulWendt
Compilers do different things differently. When a windows
program crashes, you typically either get a window and then the
program is killed by the OS ... or you get a Blue Screen of Death.
On unix, the program terminates and you get a core dump. I'm
not sure how to read them, but why don't you try doing cout's
[while flushing!] to see where your program is crashing?
--Paul
Please do this within [ c o d e] and [ / c o d e] brackets [withoutQuote:
Originally posted by luftwaffe
Maybe the best if I post the code snippets:
the spaces].
Reposting so it can be easily seen:
Code:#ifndef WIN32
DIR *pDirectory;
struct dirent *pDirectoryEntry;
struct stat DirectoryStat;
pDirectory = opendir(TempStruct.VersionRootDir.c_str());
if (pDirectory != 0) {
while ((pDirectoryEntry = readdir(pDirectory))) {
// check if directory can be sequenced or not
if (stat(pDirectoryEntry->d_name, &DirectoryStat) == 0) {
if (DirectoryStat.st_mode & S_IFDIR) {
TempFile = fopen((TempStruct.VersionRootDir +
pDirectoryEntry->d_name +
CurrentSettings.PathSeparator +
TempStruct.FileName).c_str(), "rb");
if (TempFile) {
fseek(TempFile, 0, SEEK_END);
if ((TempDateSize.Size = ftell(TempFile)) > -1) {
TempDateSize.Creation = pDirectoryEntry->d_name;
TempStruct.DateAndSize.insert(TempStruct.DateAndSize.end(), TempDateSize);
TempStruct.CurrentSizeOfVersionedFileKb += TempDateSize.Size;
}
fclose(TempFile);
}
}
}
}
closedir(pDirectory);
}
#else
/* windows stuff */
#endif
It's great that you posted a code snippet. Which line is causingQuote:
Originally posted by luftwaffe
Maybe the best if I post the code snippets:
As you might have known already, the logic how windows and unix does it a bit different. Unix crashes on readdir and closedir if that is 0
your crash? Put cout [with flushing] until you find out the exact
line. You say that it's crashing on readdir and closedir if that is
0 ... if WHAT is 0? If readdir is 0? If readdir is 0 you exit your
loop. Please post exactly what you're trying to say; what you've
said so far is too ambiguous.
--Paul
This is one of those times when I wish I had a Sparc sitting on my desk :) use dbx (heh I said dbg see how long it's been!), read the man pages as I've suggested...Quote:
Originally posted by luftwaffe
Paul, thank you for the reply. Couts are exactly what I did and found that one of the very few platform specific parts, the opendir, readdir crashed with null pointer exception (directory does not exist, then read from the null directory).
Just red recently that somehow dbx or whatever can read those ELF files...
man dbx (from a shell should do)
pDirectory was 0, so an if (what is already in the code) has been added. Then the path was not correct (I changed but did not post). Thank you for mentioning the code marker.
Now I go and try adb and dbg (currently cannot stop adb with q, quit, x, exit, CTRL+C, so I go to the man pages).
Alright so you've fixed your crashing problem right? You found outQuote:
Originally posted by luftwaffe
pDirectory was 0, so an if (what is already in the code) has been added. Then the path was not correct (I changed but did not post). Thank you for mentioning the code marker.
Now I go and try adb and dbg (currently cannot stop adb with q, quit, x, exit, CTRL+C, so I go to the man pages).
why you were crashing [you were calling readdir() on a null
pointer]. Why are you wanting to look at your core dump then?
--Paul
Maybe he/she wants to learn? Or make sure? Or the problem isn't fixed...but going back and reading it I think it is :) :) :)
Maybe. I don't know how else to help them anyway so I guess
the issue is closed unless they post again <shrug>.
--Paul
That part of the problem has been fixed. Crashes somewhere else again, this is why I would like to be able to understand what is in the core file. And of course to learn, since this is the only value what cannot be taken away from anyone.
I can't really help that much futher myself, other than to say read the man pages on dbx or adb. That's not much help I'm afraid to say...Quote:
Originally posted by PaulWendt
Maybe. I don't know how else to help them anyway so I guess
the issue is closed unless they post again <shrug>.
--Paul
It'll be great to be able to interpret the core file. Using cout [withQuote:
Originally posted by luftwaffe
That part of the problem has been fixed. Crashes somewhere else again, this is why I would like to be able to understand what is in the core file. And of course to learn, since this is the only value what cannot be taken away from anyone.
flushing] is a crude method at best.
Once you've narrowed the problem down to some actual code,
post it [with some details as appropriate], and we'll be able to
help you out further :)
--Paul
using Solaris and the SUN C/C++ compiler, there must be a gryphical frontend to the debugger called 'debugger'. from a shell start it with 'debugger <progname> core' and it will show you the line where the crash occurred.