[Sbcl-help] Large Executable Cores Crashing on Startup - Sometimes

[Burton Samograd]

Hello,

I am working on saving test data to an executable core file using sbcl
and it's working some of the time. The saving goes fine, but when I try
to run the resulting core file I get a crash. Here is a log of a bit of
a gdb session with a crashing core and my sbcl version is git HEAD. I'll
add that the cores are large (> 1GB) and I am forking before I do save:

. Any idea why this might be happening?

[ ~/petri-dish ] ./test.core
internal error #30 (division by zero)
SC: 20, Offset: 0 0xae24f28dd5af5c4: pad1:
196069080511724913
SC: 20, Offset: 6 0x00000000: even fixnum: 0
fatal error encountered in SBCL pid 17511(tid 140737353946912):
internal error too early in init, can't recover


Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb> quit
Really quit? [y] y
[ ~/petri-dish ] gdb test.core
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/burton/petri-dish/test.core...done.
(gdb) r
Starting program: /home/burton/petri-dish/test.core
[Thread debugging using libthread_db enabled]

Program received signal SIGUSR1, User defined signal 1.
0x00007ffff73cc687 in kill () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) up
#1 0x0000000000411516 in see_if_sigaction_nodefer_works () at
interrupt.c:1691
1691 kill(getpid(), SA_NODEFER_TEST_KILL_SIGNAL);
(gdb) up
#2 0x0000000000414460 in interrupt_init () at interrupt.c:1828
1828 see_if_sigaction_nodefer_works();
(gdb) down
#1 0x0000000000411516 in see_if_sigaction_nodefer_works () at
interrupt.c:1691
1691 kill(getpid(), SA_NODEFER_TEST_KILL_SIGNAL);
(gdb) list
1686 {
1687 sigset_t empty;
1688 sigemptyset(&empty);
1689 thread_sigmask(SIG_SETMASK, &empty, 0);
1690 }
1691 kill(getpid(), SA_NODEFER_TEST_KILL_SIGNAL);
1692 while (sigaction_nodefer_works == -1);
1693 sigaction(SA_NODEFER_TEST_KILL_SIGNAL, &old_sa, NULL);
1694 }
1695
(gdb) bt
#0 0x00007ffff73cc687 in kill () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x0000000000411516 in see_if_sigaction_nodefer_works () at
interrupt.c:1691
#2 0x0000000000414460 in interrupt_init () at interrupt.c:1828
#3 0x000000000040a99d in main (argc=1, argv=0x7fffffffea48,
envp=0x7fffffffea58) at runtime.c:367
(gdb) quit
A debugging session is active.

Inferior 1 [process 17514] will be killed.
[ ~/petri-dish ] sbcl --version
SBCL 1.0.57.55-80ad081-dirty
[ ~/petri-dish ]

--
Burton Samograd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sbcl-help mailing list
Sbcl...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

[Troy Noble]

Since I didn't see a response I will "take a swing" and throw out a couple of general follow-up questions...

1. why load so much data into an executable image?

2. why could the data not be dumped/stored in one or more .lisp files using some sort of smart pretty-printer, then pre-compile to a .fasl and distribute them alongside your executable, and then load the .fasl's & piece them together in memory at runtime?

If your data is horribly complex beyond just being big lists-of-lists-of-atoms, then you might need to flatten it... or you may need a really smart pretty printer and/or serialization/deserialization mechanism which my be a drawback to this approach admittedly.  I don't know what your data looks like, so it is hard to say.

The .fasl approach would also allow you to show a "loading data, please wait... this could take a while" message to the user if need be.

I guess I have never been a big fan of "load GB of goo into memory and save it to an executable approach"... since having multi-GB executable goes against my better sensibilities in terms of where to blur the line between code and data.  GB of preloaded data structure feels like data more than code to me.  That is my opinion however, for what it is worth :-)

Loading a fasl should not be much slower than loading the data from the executable image file I would imagine since it is pre-compiled code, but would need to try it to be sure.

; -- This is data1.lisp

; Define a global data structure

(defvar *data1*

 '(("a" (1 2))

   ("b" (3 4))

   ("c" (5 6))))

; -- end of data1.lisp

$ sbcl

* (compile-file "./data1.lisp")

Then at runtime: (load "./data1.fasl") after which you can access *data1*.  If you have multiple data files you could have a cascade-loading approach that then stuffs them all into one "master list" of some sort.

May also want to use packages to compartmentalize the "global" data if you don't want them to clutter cl-user or whatever package you are using for your code.

[Sbcl-help] Large Executable Cores Crashing on Startup - Sometimes From: Burton Samograd <burton.samograd@gm...> - 2012-07-07 20:34

[Burton Samograd]

On 12-07-08 09:55 AM, Troy Noble wrote:
> Since I didn't see a response I will "take a swing" and throw out a couple of general follow-up questions...
>
> 1. why load so much data into an executable image?

Because I want to.

>
> 2. why could the data not be dumped/stored in one or more .lisp files using some sort of smart pretty-printer, then pre-compile to a .fasl and distribute them alongside your executable, and then load the .fasl's & piece them together in memory at runtime?

Because I want to store the data in a lisp image.

>
> If your data is horribly complex beyond just being big lists-of-lists-of-atoms, then you might need to flatten it... or you may need a really smart pretty printer and/or serialization/deserialization mechanism which my be a drawback to this approach admittedly. I don't know what your data looks like, so it is hard to say.

It's not complicated, I just want to store it in my image.

>
> The .fasl approach would also allow you to show a "loading data, please wait... this could take a while" message to the user if need be.

I'm not writing software for other people, just myself.

> I guess I have never been a big fan of "load GB of goo into memory and save it to an executable approach"... since having multi-GB executable goes against my better sensibilities in terms of where to blur the line between code and data. GB of preloaded data structure feels like data more than code to me. That is my opinion however, for what it is worth :-)
>
> Loading a fasl should not be much slower than loading the data from the executable image file I would imagine since it is pre-compiled code, but would need to try it to be sure.
>
> ; -- This is data1.lisp
> ; Define a global data structure
> (defvar *data1*
> '(("a" (1 2))
> ("b" (3 4))
> ("c" (5 6))))
> ; -- end of data1.lisp
>
> $ sbcl
> * (compile-file "./data1.lisp")
>
> Then at runtime: (load "./data1.fasl") after which you can access *data1*. If you have multiple data files you could have a cascade-loading approach that then stuffs them all into one "master list" of some sort.

I can look into loading fasls but I was hoping to use the feature of dumping core files because it seemed very convenient.

> May also want to use packages to compartmentalize the "global" data if you don't want them to clutter cl-user or whatever package you are using for your code.

Yes, I could do that.

Since what I want to do won't work with SBCL I will look for other options.

[Burton Samograd]

On 12-07-10 06:09 AM, Troy Noble wrote:
> Perhaps the size of the image is a red herring and not really the problem at all.

I think so but so far that's all that's been concentrated on.

> I have been following the other thread of discussion about divide-by-zero with random
> numbers close to zero in the denominator.
>
> Is this possible the same set of data you are trying to dump to the image file?

It is the same code, but from what I can see the divide by zero I'm seeing is happening before the repl
even loads (see the GDB stacktrace in the original message) so none of my code looks to have even been
called yet, and I didn't even set a custom startup function for the core.


> I am almost wondering if you could be tripping over the same divide-by-zero issue when the image is
> loading? That might explain the randomness of the failures you described.
>
> It would be an interesting exercise to try to produce a repeatable test case using various "corner case"
>numeric values such as 0, -0, 0.0+/-epsilon, +/-INF, +/-NAN and so forth, and dump that data set to a
>much smaller image file, and then try to load it. If it fails you would have a repeatable test case to
> report as well, or you could easily narrow it down to values to be avoided.

The randomness isn't with the loading, it's with the cores. As in, some cores crash on startup but which ones
seems to be random.