headers
Didier Verna | 1 Jul 2012 11:53
X-Face
Face
Picon
Picon
Picon
Picon
Gravatar

sb-grovel and the CC env var


  Hi,

when you try to load a system which uses sb-grovel, without a CC
environment variable set, SBCL breaks:

The CC environment variable has not been set in SB-GROVEL. Since this variable should always be set during
the SBCL build process, this might indicate an SBCL with a broken contrib installation.
   [Condition of type SIMPLE-ERROR]

Restarts:
 0: [RETRY] Retry compiling #<GROVEL-CONSTANTS-FILE "com.dvlsoft.clon" "termio" "sbcl" "constants">.
 1: [ACCEPT] Continue, treating compiling #<GROVEL-CONSTANTS-FILE "com.dvlsoft.clon" "termio"
"sbcl" "constants"> as having been successful.
 2: [RETRY] Retry SLIME REPL evaluation request.
 3: [*ABORT] Return to SLIME's top level.
 4: [REMOVE-FD-HANDLER] Remove #<SB-IMPL::HANDLER INPUT on descriptor 6: #<CLOSURE (LABELS
SWANK-BACKEND::RUN :IN SWANK-BACKEND:ADD-FD-HANDLER) {100403C5FB}>>
 5: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP SB-GROVEL:GROVEL-CONSTANTS-FILE)) ..)
  1: ((SB-PCL::EMF ASDF:PERFORM) #<unavailable argument> #<unavailable argument> #<ASDF:COMPILE-OP
NIL {100497B403}> #<SB-GROVEL:GROVEL-CONSTANTS-FILE "com.dvlsoft.clon" "termio" "sbcl" "constants">)
  2: ((SB-PCL::FAST-METHOD ASDF::PERFORM-WITH-RESTARTS :AROUND (T T)) ..)
  3: ((LAMBDA () :IN ASDF::PERFORM-PLAN))
  4: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN SB-C::%WITH-COMPILATION-UNIT))
  5: ((FLET SB-C::WITH-IT :IN SB-C::%WITH-COMPILATION-UNIT))
  6: ((SB-PCL::FAST-METHOD ASDF::PERFORM-PLAN (LIST)) ..)
  7: ((LAMBDA () :IN ASDF:OPERATE))
(Continue reading)

Permalink | Reply | 4 comments |
headers
Burton Samograd | 7 Jul 2012 22:34
Picon
Gravatar

Large Executable Cores Crashing on Startup - Sometimes

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".
(Continue reading)

Permalink | Reply | 2 comments |
headers
Burton Samograd | 8 Jul 2012 02:44
Picon
Gravatar

Odd Division By Zero Error

After running my simulation code for a few minutes I get the following
DIVISION-BY-ZERO error:

debugger invoked on a DIVISION-BY-ZERO in thread
#<THREAD "main thread" RUNNING {1002978F23}>:
  arithmetic error DIVISION-BY-ZERO signalled

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY   ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file
"/home/burton/petri-dish/pd-smoother.lisp".
  2: [ABORT   ] Abort loading file "/home/burton/petri-dish/pd-smoother.lisp".
  3:            Exit debugger, returning to top level.

("bogus stack frame")
0] down
(TURN
    #S(ANIMAL
       :NAME 255864
       :X 917
       :Y 369
       :DX 0
       :DY -0.5338847560008251d0
       :ENERGY 12.935097
       :DIR 2.5060025128981067d0
       :GENES (16.031828 18.04544 4.023058 6.024463 5.013414 47.029236
               159.04361 101.0075 9.032942 20.054955 13.022877 15.029232 ...)
       :GENE-CHOICE-SUM 83.23452
(Continue reading)

Permalink | Reply | 24 comments |
headers
Kevin Reid | 8 Jul 2012 03:03
Favicon
Gravatar

Re: Odd Division By Zero Error

On Jul 7, 2012, at 17:44, Burton Samograd wrote:

> Here is the definition of normal, which has no divisions:
> 
> (defun normal (&optional (a 1.0) (s 0.5))
>  (+ a (* (sqrt (* -2 (log (random 1.0)))) (cos (* 2 pi (random 1.0))) s)))
> 
> Any idea where this division by zero error might be coming from?

RANDOM may return 0.0 in which case LOG will (on SBCL) signal DIVISION-BY-ZERO.

--

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>

------------------------------------------------------------------------------
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/
Permalink | Reply | 23 comments |
headers
Burton Samograd | 8 Jul 2012 04:23
Picon
Gravatar

Re: Odd Division By Zero Error

On 12-07-07 07:03 PM, Kevin Reid wrote:
> On Jul 7, 2012, at 17:44, Burton Samograd wrote:
>
>> Here is the definition of normal, which has no divisions:
>>
>> (defun normal (&optional (a 1.0) (s 0.5))
>>   (+ a (* (sqrt (* -2 (log (random 1.0)))) (cos (* 2 pi (random 1.0))) s)))
>>
>> Any idea where this division by zero error might be coming from?
> RANDOM may return 0.0 in which case LOG will (on SBCL) signal DIVISION-BY-ZERO.
>
Ah, I had a feeling it was something like that but the division by zero 
was throwing me off.

Thanks. I got that line from Rosetta Code; maybe it should be fixed.  
What is a good fix for this? I'm thinking that adding a very small value 
to the result of random might suffice but I don't like it.

--
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/
Permalink | Reply | 22 comments |
headers
Jeffrey Cunningham | 8 Jul 2012 05:02
Gravatar

Re: Odd Division By Zero Error


On 07/07/2012 07:23 PM, Burton Samograd wrote:
On 12-07-07 07:03 PM, Kevin Reid wrote:
On Jul 7, 2012, at 17:44, Burton Samograd wrote:
Here is the definition of normal, which has no divisions: (defun normal (&optional (a 1.0) (s 0.5)) (+ a (* (sqrt (* -2 (log (random 1.0)))) (cos (* 2 pi (random 1.0))) s))) Any idea where this division by zero error might be coming from?
RANDOM may return 0.0 in which case LOG will (on SBCL) signal DIVISION-BY-ZERO.
Ah, I had a feeling it was something like that but the division by zero was throwing me off. Thanks. I got that line from Rosetta Code; maybe it should be fixed. What is a good fix for this? I'm thinking that adding a very small value to the result of random might suffice but I don't like it. -- Burton Samograd

Adding a small amount would warp the distribution (a tiny amount). But this will work and won't:

(defun normal (&optional (a 1.0) (s 0.5))
  (+ a (* (sqrt (* -2 (log (- 1.0 (random 1.0))))) (cos (* 2 pi (random 1.0)))
  s)))

According to the spec, random produces numbers always less than the limit so it will never hit zero. And its a uniform distribution so you haven't changed its statistical properties.

Jeff Cunningham

------------------------------------------------------------------------------
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-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
Permalink | Reply | 21 comments |
headers
Troy Noble | 8 Jul 2012 17:55
Picon

Re: Large Executable Cores Crashing on Startup - Sometimes

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 <at> gm...> - 2012-07-07 20:34
------------------------------------------------------------------------------
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-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
Permalink | Reply | 1 comment |
headers
Jeffrey Cunningham | 9 Jul 2012 02:01
Gravatar

Re: Odd Division By Zero Error


On 07/07/2012 08:02 PM, Jeffrey Cunningham wrote:

On 07/07/2012 07:23 PM, Burton Samograd wrote:
On 12-07-07 07:03 PM, Kevin Reid wrote:
On Jul 7, 2012, at 17:44, Burton Samograd wrote:
Here is the definition of normal, which has no divisions: (defun normal (&optional (a 1.0) (s 0.5)) (+ a (* (sqrt (* -2 (log (random 1.0)))) (cos (* 2 pi (random 1.0))) s))) Any idea where this division by zero error might be coming from?
RANDOM may return 0.0 in which case LOG will (on SBCL) signal DIVISION-BY-ZERO.
Ah, I had a feeling it was something like that but the division by zero was throwing me off. Thanks. I got that line from Rosetta Code; maybe it should be fixed. What is a good fix for this? I'm thinking that adding a very small value to the result of random might suffice but I don't like it. -- Burton Samograd

Adding a small amount would warp the distribution (a tiny amount). But this will work and won't:

(defun normal (&optional (a 1.0) (s 0.5))
  (+ a (* (sqrt (* -2 (log (- 1.0 (random 1.0))))) (cos (* 2 pi (random 1.0)))
  s)))

According to the spec, random produces numbers always less than the limit so it will never hit zero. And its a uniform distribution so you haven't changed its statistical properties.

Jeff Cunningham

Have you looked at a distribution of the outputs? I'm wondering if there's something else wrong. You really shouldn't see zero show up as an argument to log except once in a blue moon.

It might be very small numbers will kill log also. If that's the case, then you could figure out the threshold for smallest argument to log, and put some logic in there to exclude those cases (regen another uniform variate).

Jeff Cunningham


------------------------------------------------------------------------------
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-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
Permalink | Reply | 20 comments |
headers
Burton Samograd | 9 Jul 2012 05:39
Picon
Gravatar

Re: Odd Division By Zero Error

On 12-07-08 06:01 PM, Jeffrey Cunningham wrote:
>
> On 07/07/2012 08:02 PM, Jeffrey Cunningham wrote:
>>
>> On 07/07/2012 07:23 PM, Burton Samograd wrote:
>>> On 12-07-07 07:03 PM, Kevin Reid wrote:
>>>> On Jul 7, 2012, at 17:44, Burton Samograd wrote:
>>>>
>>>>> Here is the definition of normal, which has no divisions:
>>>>>
>>>>> (defun normal (&optional (a 1.0) (s 0.5))
>>>>>    (+ a (* (sqrt (* -2 (log (random 1.0)))) (cos (* 2 pi (random 1.0))) s)))
>>>>>
>>>>> Any idea where this division by zero error might be coming from?
>>>> RANDOM may return 0.0 in which case LOG will (on SBCL) signal DIVISION-BY-ZERO.
>>>>
>>> Ah, I had a feeling it was something like that but the division by zero
>>> was throwing me off.
>>>
>>> Thanks. I got that line from Rosetta Code; maybe it should be fixed.
>>> What is a good fix for this? I'm thinking that adding a very small value
>>> to the result of random might suffice but I don't like it.
>>>
>>> --
>>> Burton Samograd
>>
>> Adding a small amount would warp the distribution (a tiny amount). 
>> But this will work and won't:
>>
>> (defun normal (&optional (a 1.0) (s 0.5))
>>   (+ a (* (sqrt (* -2 (log (- 1.0 (random 1.0))))) (cos (* 2 pi 
>> (random 1.0)))
>>   s)))
>>
>> According to the spec, random produces numbers always less than the 
>> limit so it will never hit zero. And its a uniform distribution so 
>> you haven't changed its statistical properties.
>>
>> Jeff Cunningham
>>
> Have you looked at a distribution of the outputs? I'm wondering if 
> there's something else wrong. You really shouldn't see zero show up as 
> an argument to log except once in a blue moon.

That was the problem.  I'm running a simulation with hundreds of 
thousands of agents and that blue moon shows up pretty frequently. I 
tried your idea of subtracting from 1 on CCL (SBCL is being too finicky 
right now) and it doesn't seem to follow the standard of [0.0...1.0).  I 
ended up just adding 1E-32 to (random 1.0); I really don't think it will 
make a difference (famous last words).
> It might be very small numbers will kill log also. If that's the case, 
> then you could figure out the threshold for smallest argument to log, 
> and put some logic in there to exclude those cases (regen another 
> uniform variate).
Maybe but since my tiny addition I haven't had the problem so I'm 
satisfied with it as a solution for now.
>
> Jeff Cunningham
>
--
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/
Permalink | Reply | 1 comment |
headers
Jeffrey Cunningham | 9 Jul 2012 06:11
Gravatar

Re: Odd Division By Zero Error


On 07/08/2012 08:39 PM, Burton Samograd wrote:
That was the problem. I'm running a simulation with hundreds of thousands of agents and that blue moon shows up pretty frequently. I tried your idea of subtracting from 1 on CCL (SBCL is being too finicky right now) and it doesn't seem to follow the standard of [0.0...1.0). I ended up just adding 1E-32 to (random 1.0); I really don't think it will make a difference (famous last words).
It might be very small numbers will kill log also. If that's the case, then you could figure out the threshold for smallest argument to log, and put some logic in there to exclude those cases (regen another uniform variate).
Maybe but since my tiny addition I haven't had the problem so I'm satisfied with it as a solution for now.
Jeff Cunningham
-- Burton Samograd
Careful that U+epsilon doesn't exceed 1.0 or you will mess up the distribution where it counts. It probably would be better to throw away U's that are less than epsilon. All your doing then is cutting off the tails way out there somewhere.

Jeff Cunningham
------------------------------------------------------------------------------
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-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
Permalink | Reply | 0 comments |

Gmane