[Openmcl-devel] Another linux86-32: signed doubleword parameters.
lisp at davidb.org
Mon Oct 13 16:11:51 UTC 2008
On Mon, Oct 13, 2008 at 06:20:04AM -0600, Gary Byers wrote:
> When sockets are involved, are threads also involved ? (Threads
> generally offer more ways for things to go wrong; sockets are mostly
> just streams and are probably no more likely to scribble over memory
> than other streams are.)
Yes, I was about to post another message mentioning that this was also
when threads got involved in the picture. You're right, the sockets
probably don't have much to do with it.
> Whether or not the integrity checks are performed is controlled
> by a bit in the fixnum which is the global value of the variable
> CCL::*GC-EVENT-STATUS-BITS*; doing:
> It's sometimes very hard to debug this kind of problem, and even harder to
> explain to someone else how to do so. It -might- be interesting to see
> what gets reported if you run your code with integrity checking on, but
> in practice it's probably necessary for us to either run that code or
> run something similar that triggers the same. If you can send us your
> code, we can try to figure out what's going on.
I've debugged plenty of GC/memory errors, so I have some idea of what
is going on.
Let me poke around a bit and see if anything is obvious.
So, first crash is "Exception occurred while executing foreign code."
Exception occurred while executing foreign code
at mark_root + 45
My code does make fairly heavy usage of 'with-pointer-to-ivector'.
Perhaps %log-gc-lock (without-gcing) isn't working, and another thread
is starting a garbage collection while the other CPU is running the
Basically, a good portion of the CPU time of the application is spent
inside of zlib with pointers to lisp heap data. At some point, I
might change this to use foreign pointers, but then I have to worry
about space leaks and such.
I do also have multiple CPUs.
More information about the Openmcl-devel