Member Discussions

Hi there, we're having some problems with crashes and trying to use gdb. The program exits before a backtrace can even be done, and for some reason it doesn't dump a core file. We've read about core size limits, but using ulimit -c says it's already unlimited. ulimit -c unlimited is already in .bash_profile too. And we can't even begin to figure out why the program exits before a bt can be done or what needs to be done to stop it from exiting right after a crash.


Any help would be greatly appreciated.


(Using QuickMUD with CYGWIN)

Hi there, we're having some problems with crashes and trying to use gdb. The program exits before a backtrace can even be done, and for some reason it doesn't dump a core file. We've read about core size limits, but using ulimit -c says it's already unlimited. ulimit -c unlimited is already in .bash_profile too. And we can't even begin to figure out why the program exits before a bt can be done or what needs to be done to stop it from exiting right after a crash.


Any help would be greatly appreciated.


(Using QuickMUD with CYGWIN)


There's a known problem with Cygwin/coredumps (lack of), which Tyche managed to track down to hardware incompatability. As I recall it applies to AMD processors, and hadn't been fixed last time I checked.

If this is the problem in your case, you might have better success running the mud under gdb, rather than waiting for it to crash first.

If you know what crashes it, you can probably put in a breakpoint before the crash point and singlestep from there.

It's an intel processor and we're still not able to get core files, but were finally able to backtrace once before the program exited. Backtrace showed:

Program receieved signal SIGSEGV, Segmentation fault.
0x610409e1 in mktime () from /usr/bin/cygwin1.dll
bt
#0 0x610409e1 in mktime () from /usr/bin/cygwin1.dll
#1 0x6104079f in mktime () from /usr/bin/cygwin1.dll
#2 0x610413e6 in malloc () from /usr/bin/cygwin1.dll
#3 0x610c5d49 in wmemset () from /usr/bin/cygwin1.dll
#4 0x610c244c in wmemset () from /usr/bin/cygwin1.dll
#5 0x610bf816 in vfprintf () from /usr/bin/cygwin1.dll
#6 0x610bf70c in vfprintf () from /usr/bin/cygwin1.dll
#7 0x610b383f in fprintf () /usr/bin/cygwin1.dll
#8 0x00483713 in save_area_list () at old_save.c: 96
#9 0x00485c3f in do_asave (ch=0xa1b9f20, argument=0xa1b479b 'changed') at olc_save.c:1038
#10 0x00453be0 in interpret (ch=0xa1b9f20, argument=0xa1b4795 'asave changed') at interp.c:591
#11 0x0042cf9a in substitute_alias (d=0xa1b3f90, argument=0xa1b4795 'asave changed') at alias.c:102
#12 0x00431c1b in game_loop_unix (control=5) at comm.c:829
#13 0x00431674 in main (argc=2, argv=0xa040fd0) at comm.c:448

To get it to crash, we use the set command to set stats about 10 times, then use 'asave changed' or any other command using fprintf. Using those commands before all the setting usually works fine without crashing.

Any suggestions or tips on how to find the problem with fprintf, if that's really the problem, would be very appreciated.

We've tried using breakpoints for everything from mktime to wmemset, but gdb didn't stop before the crash. When we tried it with vfprintf and fprintf it stopped but only said 'Single stepping until exit from function vfprintf, which has no line number information.' over and over until a normal crash happens with no dumped core or possible backtrace.

It's likely that the problem lies in the last functions called within the mud code, rather than function calls within cygwin - ie
#8 0x00483713 in save_area_list () at old_save.c: 96
#9 0x00485c3f in do_asave (ch=0xa1b9f20, argument=0xa1b479b 'changed') at olc_save.c:1038

Thus the fault appears to lie in saving the area list, so check if that has become corrupted in some way.

Try putting your breakpoints there, and printing out values of the variables there.

If that doesn't show you where the problem lies, then post a few lines of code around those points.

I used breakpoints in functions using fprintf and they're all like...

Breakpoint 1, save_area_list () at olc_save.c:81
81 if ((fp = fopen ('area.lst', 'w')) == NULL)
step
94 for (pArea = area_first; pArea; pArea = pArea->next)

96 fprintf (fp, '%s\n', pArea->file_name);

Program receieved signal SIGSEGV, Segmentation fault.
0x610409e1 in mktime () from /usr/bin/cygwin1.dll
bt
#0 0x610409e1 in mktime () from /usr/bin/cygwin1.dll
#1 0x6104079f in mktime () from /usr/bin/cygwin1.dll
#2 0x610413e6 in malloc () from /usr/bin/cygwin1.dll
#3 0x610c5d49 in wmemset () from /usr/bin/cygwin1.dll
#4 0x610c244c in wmemset () from /usr/bin/cygwin1.dll
#5 0x610bf816 in vfprintf () from /usr/bin/cygwin1.dll
#6 0x610bf70c in vfprintf () from /usr/bin/cygwin1.dll
#7 0x610b383f in fprintf () /usr/bin/cygwin1.dll
#8 0x00483713 in save_area_list () at old_save.c: 96
#9 0x00485c3f in do_asave (ch=0xa1b9f20, argument=0xa1b479b 'changed') at olc_save.c:1038
#10 0x00453be0 in interpret (ch=0xa1b9f20, argument=0xa1b4795 'asave changed') at interp.c:591
#11 0x0042cf9a in substitute_alias (d=0xa1b3f90, argument=0xa1b4795 'asave changed') at alias.c:102
#12 0x00431c1b in game_loop_unix (control=5) at comm.c:829
#13 0x00431674 in main (argc=2, argv=0xa040fd0) at comm.c:448

A couple places it crashes are...

void save_area_list ()
{
FILE *fp;
AREA_DATA *pArea;

if ((fp = fopen ('area.lst', 'w')) == NULL)
{
bug ('Save_area_list: fopen', 0);
perror ('area.lst');
}
else
{
for (pArea = area_first; pArea; pArea = pArea->next)
{
--> fprintf (fp, '%s\n', pArea->file_name); <-- crash here
}
fprintf (fp, '$\n');
fclose (fp);
}
return;
}

and to write disabled commands to a file...

for (p = disabled_first; p ; p = p->next)
fprintf (fp, '%s %d %s\n', p->command->name, p->level, p->disabled_by); <-- crash here

Anything using fprintf crashes most of the times they're used. The files open but nothing is written to them so they're empty after the crash.

All the code I've checked seems fine and is the same as it always has been, so now I'm not sure what to try. I just tried replacing cygwin1.dll with different versions (I'm not sure if that would even change anything) just incase mine got messed up somehow but that didn't change anything. I tried running QuickMUD without any changes incase we've always had this problem and just didn't notice somehow, but I couldn't cause a crash.

And thanks for your replies...we've been trying to figure this out for a while and any help is greatly appreciated!

As you are crashing on the line :
--> fprintf (fp, '%s\n', pArea->file_name); <-- crash here
it looks as if pArea->file_name is invalid.

Try printing that out within gdb. Also print out the values of area_first and pArea->next. It's likely that one (or more) of these is null.

Alternatively add some debugging code to display the value of that each time it goes through the loop, so that you can see the last area it processes successfully before it crashes.

It's fixed! It ended up having nothing to do with anything we thought it did, heh.

We just went back a few versions and did some trial and error re-adding things that were in the newer versions. The problem was something we did in score putting the character name and title together in one variable, but we (obviously) did it incorrectly, so after typing score things got messed up. We're all back to normal now and very relieved!

Thanks a ton for all your help, we learned how to use gdb better at least :D