Fork()?
Goto page Previous  1, 2
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding
View previous topic :: View next topic  
Author Message
Traithe



Joined: 13 May 2005
Posts: 50

PostPosted: Thu May 19, 2005 9:39 pm    Post subject: Reply with quote

It wasn't actually an infinite loop, Eiz - at least, not judging from the CPU usage, which dropped to 0% after the server froze.

I'm guessing it had something to do with the child process not exiting properly and signalling the parent, so the parent remained in a perpetual wait state.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Thu May 19, 2005 11:14 pm    Post subject: Reply with quote

eiz wrote:
Tyche wrote:

So where is the above crash logging routine, gdbdump() called from?


In the SEGV handler I guess. But judging from the symptoms, I'd guess that he was a bit too aggressive in setting up signal handlers. The only way I was able to get a similar infinite loop in a test program was to set SIGCHLD to the same handler. Of course, it's very difficult to reproduce the exact conditions since the heap could be in some horribly damaged state, but this seems most likely.


I'm not sure about solving this particular problem, I don't think it's worth solving. I'm just trying convey that the kind of things that are being attempted here in SEGV are unreliable. Also if userspace is corrupted, fork() nicely copies that to the child, which is the point of this but also the bane of what one might attempt in the child. The child could easily SEGV.

Kyuss wrote:

Mainly I just run in debug mode and pray for a crash, which of course
never, ever happens.


If by run in debug mode you mean under gdb, then you won't ever get a core dump (well unless gdb crashes itself)
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kyuss



Joined: 13 May 2005
Posts: 37
Location: Southern Hellinois

PostPosted: Thu May 19, 2005 11:35 pm    Post subject: Reply with quote

Quote:
If by run in debug mode you mean under gdb, then you won't ever get a core dump (well unless gdb crashes itself)


I just leave it up in gdb all day so when it crashes I can fix it.
I get about 1 core file a year.

Quote:
If not, try doing "ulimit -a"


my version of bsd doesnt have ulimit Sad
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
Author Message
eiz



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Thu May 19, 2005 11:38 pm    Post subject: Reply with quote

Kyuss wrote:

my version of bsd doesnt have ulimit Sad


It's a shell thing. I don't know what the csh equivalent is. If you always run it under gdb, like Tyche said, you won't ever get a core dump.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Traithe



Joined: 13 May 2005
Posts: 50

PostPosted: Fri May 20, 2005 4:32 am    Post subject: Reply with quote

Well, for all the hemming and hawing about the evils of continuing execution after a SEGV, the debug dump seems to be working fine.

I'm sure it's quite possible that a crash will so corrupt things that the debug output would be useless, but I'm a pragmatist. Wink If it seems to work reasonably well, then that's good enough for me.

I'll leave it to the CS people to debate the intricacies of stack corruption and re-entry. Cool

(Oh, and fyi, the infinite recursion scenario isn't really an issue here - barring the possibility of corruption discussed above, anyway - as there's code in place to catch the existence of more than one fork and take down the program if that happens.)
Back to top
View user's profile Send private message Visit poster's website
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Fri May 20, 2005 9:15 am    Post subject: Reply with quote

Code:

void gdbdump ( char *strGdbCommandFile, char *strFilterScript )
{
   FILE      *fp, *lp;
   char      buf [1024] = "";
   int      pid = -1;
   
unsafe ====>   alog(logger::NOTICE) << "Crash intercepted for recording.";

   pid = fork();
   
   if ( pid == 0 ) {
unsafe ====>      sprintf (buf, "%s -silent -x %s/src/gdbdump.ini %s/bin/%s %d",
         GDB_PATH, PATH_TO_TOPDIR, PATH_TO_TOPDIR, NAME_OF_BINARY, getppid());

unsafe ====>      alog (logger::NOTICE) << buf;

unsafe ====>      fp = popen (buf, "r");
unsafe ====>      lp = fopen ("crash", "w");
   
unsafe ====>      while ( !feof (fp) ) {
unsafe ====>         fgets (buf, 512, fp);
unsafe ====>         fputs (buf, lp);
      }

unsafe ====>      fclose (lp);
unsafe ====>      fclose (fp);

      exit(2);
   }
   
   waitpid (pid, 0, 0);
   
unsafe ====>   alog (logger::NOTICE) << "End of gdbdump() reached successfully.";
}


That's just from reading the man page.

Traithe wrote:
Well, for all the hemming and hawing about the evils of continuing execution after a SEGV, the debug dump seems to be working fine.


This works perfectly fine on my system:
Code:

#include <stdio.h>

main() {
char x[5];
strcpy(x,"Hello World");
printf("%s\n",x);
}


I just bumped that number between the bracket thingies from 4 to 5, and bingo problem fixed.

Traithe wrote:

I'm sure it's quite possible that a crash will so corrupt things that the debug output would be useless, but I'm a pragmatist. Wink If it seems to work reasonably well, then that's good enough for me.

I'll leave it to the CS people to debate the intricacies of stack corruption and re-entry. Cool


There's really no hemming and hawing here, just a .....reluctance to provide advice to CM people.

I'm lazy and pragmatic. I have 3 lines in my mud startup script. I keep me cores and archive them. I could instead if I wanted to, change one line, add another to run the silent gdb on them, concat it to the log and automatically delete the cores.

You can also read and choose to ignore Posix says about C++ exception handling and signals. And find out what Ruby uses SIGABRT and SIGALRM for or not.

We did have this conversation sometime back on TMC. I had it before on usenet with the inventor of the crash-proof mud snippet, whose brilliant work inspired legions of follow-on posts by those using it over the years which can be best summed up as "My mud automatically resets/locks up every half hour to 3 hours. No it isn't crashing, I get no output, but WTF is going on here?"
Back to top
View user's profile Send private message Visit poster's website
Author Message
Traithe



Joined: 13 May 2005
Posts: 50

PostPosted: Sun May 29, 2005 8:56 am    Post subject: Reply with quote

All right, all right.

Crotchety old man / code-fu Grandmaster Tyche 1, Traithe 0.

I yanked this sucker out earlier tonight after it mangled some crash output into an unusable state.

Old-fashioned core dumps it is, looks like. Shocked
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign