Matthew,
Sorry I am a bit late on this. It is good to know that you keep
track on crash reports even as vague as mine. Here is an update:
-- My crash remains with the nightly build that I installed on Saturday
(Oct 3);
-- I do not use places;
-- I do not use any new advanced macro facilities (not directly at least);
-- On the previous build, I tried fixing AGE_GEN_0_TO_GEN_HALF to 1 as
you suggested. It did not provoke faster crash.
I have not yet tried your rewind-gc branch.
I am going to get you a stack trace.
Am I correct that in order to get the stack trace, I have to rebuild
Racket with -G and run it in gdb?
Here is another interesting thing that I was able to notice.
As soon as I purged the "compiled" directories from the code tree,
the crashes ceased. I did several consecutive successful runs.
I ran just "racket myprogram", without "raco make" or DrRacket.
Then I executed "raco make myprogram" -- and the very next run
has crashed after ~7h of running.
How do you think, does it make sense that stored bytecode can
cause the crash or is it just a coincidence?
Best regards,
Dmitry
On 10/03/2015 03:27 PM, Matthew Flatt wrote:
I imagine that the "rewind-gc" branch was no help at all. At the time
of your post, there were several open crash reports; I've now resolved
all of them except yours, and none of the others had to do with GC
changes. (One was related to the new macro system, and two were old
bugs in places.)
If you can get any sort of crash report with a stack trace, that
information is often enough for me to either track down the problem or
at least say something about what parts of the example may be relevant.
Thanks,
Matthew
At Mon, 21 Sep 2015 00:08:43 +0300, Dmitry Pavlov wrote:
Hello,
I was just able to discover that my program crashes on the
nightly build 6.2.900.17, on Linux. The program has a heavy portion
of math, double and extended unsafe ops, and accesses multiple
low-level libraries. It has crashed after 4 hours of running,
while doing just the same that it had been doing for those
4 hours.
SIGSEGV MAPERR si_code 1 fault on addr 0x7f9f0d16a008
The previous version of Racket that I used for a long time
(and saw no crashes with it) is 6.2.0.3.
Before I go into deeper analysis by trial and error, maybe
the developers (I guess it would be Matthew) could give any
insight on what has been done since 6.2.0.3 that could result
in the crash? How to stress the VM to wait less till the crash
occurs?
Best regards,
Dmitry
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
