segmentation fault: solaris

[luftwaffe]

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).

[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

[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...

[Paul McKenzie]

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...

So what happens if the Windows version runs into directories that do not exist?

Regards,

Paul McKenzie

[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; 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

[Mick]

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...

[Mick]

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

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

[PaulWendt]

Originally posted by luftwaffe
Maybe the best if I post the code snippets:

Please do this within [ c o d e] and [ / c o d e] brackets [without
the spaces].


Reposting so it can be easily seen:

#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

[PaulWendt]

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

It's great that you posted a code snippet. Which line is causing
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

[Mick]

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...

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...

man dbx (from a shell should do)

[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).

[PaulWendt]

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).

Alright so you've fixed your crashing problem right? You found out
why you were crashing [you were calling readdir() on a null
pointer]. Why are you wanting to look at your core dump then?

--Paul

[Mick]

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

[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

[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.