bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crashing bug


From: Army Research Lab
Subject: Re: Crashing bug
Date: Mon, 19 Nov 2007 07:32:58 -0500
User-agent: Microsoft-Entourage/11.3.6.070618

>>> Can you come up with a stack trace (either by running gperf under gdb,
>>> or from the log file in $HOME/Library/Logs/CrashReporter/)?
>> 
>> I tried getting a stack trace, and I tried attaching it to the message I
>> sent you, but unfortunately the attachment got refused! :(
> 
> Hmm, you can try gzip or bzip it; maybe that works?
> 

I'll try that on the next trace that I get out.  Right now, I've had my
compile of gperf 3.0.3 running for more than 48 hours without any crashes.
That said, I'm running it under Xcode, in debug mode (which makes it slow,
it just might not have reached the point where it crashes yet).  I've
sprinkled breakpoints in the various locations where I think interesting
things may occur, and have hit them on occasion, indicating that good things
are happening, but I haven't had a crash yet.  Once I do, I'll log
everything I can and send it to you.

>> gperf --version returns 3.0.1... maybe there were some bug fixes???
> 
> There were no bug fixes that could be related to this crash.
> 
>> I'm not sure how long it ran; I let it run over the weekend, it seems it
>> crashed after 3 days or so, but I'm not 100% sure; I just see where the
>> terminal crashed, not where gperf crashed.  Mainly, it never completes; it
>> just goes until it crashes.
> 
> Nevertheless it should crash with a reasonable error message. On MacOS X 10.3,
> when a C++ program allocates too much memory, this is what happens:
> 
>   *** malloc: vm_allocate(size=3000000512) failed (error code=3)
>   *** malloc[11283]: error: Can't allocate region
>   Abort trap
> 
> If gperf crashes without such a message, there's something wrong. I have
> my copy running for 18 hours now, and it is still running...

There may have been, but I can't find it in the logs at this point.  I've
looked in all the usual locations (crash reporter in both my home directory
and the system directory, and even in /var/log out of desperation)

This time, I've got the debug version running (which is why it is taking so
long) so I'm pretty sure I'll have something worth reporting.

BTW, I have no idea if it is possible or not, but is the algorithm amenable
to multithreading?  I'm running on a dual quad-core Xeon machine, but only
one core is running (two, if you count XCode's needs).  It'd be handy if I
could use everything I've got rather than just one core.

Thanks,
Cem Karan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]