Re: [bdbxml] Crash in dbxml_javaJNI.XmlResults_next__SWIG_0

On Monday 12 September 2005 18:19, George Feinberg wrote:

Hi George,

thanks for your help, we appreciate that very much.
> 
> I cannot, in fact reproduce the error with the rewritten code.
We can reproduce the bug on several machines here. However it
happens not always, but quite often (on hyperthreading cpus, see
below).

> The behavior you are seeing is what I was able to reproduce
> with the old code.  I don't think it's a build issue.
> 
> Because the crash occurs when deleted memory is referenced,
> a memory-checking tool, such as valgrind can help debug
> the problem.  Can you try running under valgrind to see
> if it can be further isolated?
I tried it with valgrind, but did not have real success. I think
that is because we run the the test program through java where
we do not have sources nor debug versions. 

All valgrind spits out is the following:

valgrind --tool=memcheck java -Djava.library.path=$DBXML/ MultithreadingTestCase
==26541== Memcheck, a memory error detector for x86-linux.
==26541== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==26541== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==26541== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==26541== For more details, rerun with: -v
==26541==
==26541== Conditional jump or move depends on uninitialised value(s)
==26541==    at 0x1B8EEE03: (within /lib/ld-2.3.4.so)
==26541==    by 0x1B8E6F7A: (within /lib/ld-2.3.4.so)
==26541==    by 0x1B8F4BC0: (within /lib/ld-2.3.4.so)
==26541==    by 0x1B8E53DA: (within /lib/ld-2.3.4.so)
==26541==
==26541==    [ some more of these ]

Creating container... done
Waiting for threads...
thread #1 done
thread #2 done
thread #3 done
thread #4 done

****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC                = 0x08197dba
SIGNAL            = 11
FUNCTION NAME     = (N/A)
OFFSET            = 0xFFFFFFFF
LIBRARY NAME      = (N/A)
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.

=== snip ====

Is there any chance to enable more debug information from dbxml
or to let the java interpreter to give more helpfull information?
Any hints how to call valgrind more informative?

Another suspicion is that it has something to do with the kernel
we are running: It seems as if the problem happens way oftener on 
SMP kernels than on single processor kernels, however we were also 
able to reproduce it on single processor kernel.

Thanks for any help,

Klaas

-- 
                                               Klaas Freitag
                          Novell - SUSE R&D - Internal Tools


------------------------------------------
To remove yourself from this list, send an
email to [email protected]