[Openmcl-devel] Another linux86-32: signed doubleword parameters.

[David Brown]

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
foreign code.

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.

Thanks,
David