Tue 22 Feb 2005 12:35:34 PM UTC, comment #8:
On my system, it looks different in gdb:
(gdb) run Crash.exe http://10.1.1.11/test.xml
Starting program: /usr/local/bin/ilrun Crash.exe http://10.1.1.11/test.xml
[Thread debugging using libthread_db enabled]
[New Thread 1075769472 (LWP 21281)]
0
1
2
3
4
5
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1075769472 (LWP 21281)]
_ILCVMInterpreter (thread=0x8163d20) at cvm_call.c:934
934 methodToCall = (GetObjectClassPrivate(tempptr))
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
_ILCVMInterpreter (thread=0x8163d20) at cvm_call.c:934
934 methodToCall = (GetObjectClassPrivate(tempptr))
(gdb) c
Continuing.
Couldn't get registers: No such process.
(gdb)
|
Tue 22 Feb 2005 08:57:26 AM UTC, comment #7:
(gdb) run http-crash.exe http://127.0.0.1/~gopal/System.xml
Starting program: /usr/local/bin/ilrun http-crash.exe http://127.0.0.1/~gopal/System.xml
[New Thread 1024 (LWP 4135)]
0
1
2
3
4
5
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4135)]
_ILCVMInterpreter (thread=0x815ad20) at cvm.c:934
Line number 934 out of range; cvm.c has 814 lines.
(gdb) c
Continuing.
6
7
8
9
10
11
12
13
14
Program received signal SIGSEGV, Segmentation fault.
_ILCVMInterpreter (thread=0x815ad20) at cvm.c:934
Line number 934 out of range; cvm.c has 814 lines.
(gdb)
Seems to continue fine on my box.
We have to figure out why the signal handling NULL check fails on your machine.
|
Wed 16 Feb 2005 02:09:27 PM UTC, comment #6:
Duplicated bug on Mandrake Cooker, kernel 2.6.10 with CVS build of pnet.
gdb backtrace:
#0 _ILCVMInterpreter (thread=0x8163d20) at cvm_call.c:934
#1 0x0804c4dd in _ILCallMethod (thread=0x8163d20, method=0xb7ad9de0, unpack=0x804c200 <_ILCallUnpackDirectResult>,
result=0x0, isCtor=0, _this=0x0, pack=0x804be20 <_ILCallPackVaParams>, userData=0xbfffed84) at call.c:706
#2 0x0804c7ee in ILExecThreadCall (thread=0x8163d20, method=0xb7ad9de0, result=0x0) at call.c:917
#3 0x080a23a5 in _ILFinalizeObject (block=0x8317e38, data=0x0) at heap.c:163
#4 0x080e6219 in GC_invoke_finalizers () at finalize.c:787
#5 0x080ce827 in PrivateGCNotifyFinalize (timeout=0, ignoreDisabled=-1215687068) at hb_gc.c:187
#6 0x080e6c71 in GC_generic_malloc (lb=16, k=4) at malloc.c:188
#7 0x080edc43 in GC_malloc_explicitly_typed (lb=16, d=0) at typd_mlc.c:653
#8 0x080a24fb in _ILEngineAllocAtomic (thread=0x8163e70, classInfo=0xb7dbc500, size=5) at heap.c:261
#9 0x0805b84f in System_SArray_ctor (thread=0x8163e70, length=1) at lib_array.c:120
#10 0x080e3adf in ffi_call_SYSV () at src/x86/sysv.S:59
#11 0x080e3ac3 in ffi_raw_call (cif=0x8323028, fn=0x805b7d0 <System_SArray_ctor>, rvalue=0xb78a1664, fake_avalue=0x0)
at src/x86/ffi.c:515
#12 0x08099899 in _ILCVMInterpreter (thread=0x8163e70) at cvm_call.c:855
#13 0x0804c4dd in _ILCallMethod (thread=0x8163e70, method=0xb7d9b370, unpack=0x804c340 <_ILCallUnpackVResult>,
result=0xbffff450, isCtor=0, _this=0x0, pack=0x804c050 <_ILCallPackVParams>, userData=0xbffff460) at call.c:706
#14 0x0804c818 in ILExecThreadCallV (thread=0x8163e70, method=0xb7d9b370, result=0xbffff450, args=0xbffff460)
at call.c:928
#15 0x0804bd29 in main (argc=3, argv=0xbffff514) at ilrun.c:494
|
Thu 20 Jan 2005 10:00:20 AM UTC, comment #5:
This second program Crash.cs works better for reproducing the crash. It's a simple loop that opens an XmlTextReader and immediately closes it. After 4 Iterations, it segfaults on my PC... with the quickhack (see previous post) it works.
For reproducing the crash, you need to access the file from a http server; reading a local xml file does not cause the crash.
[erich@localhost erich]$ cscc Crash.cs -lSystem.Xml -o Crash.exe
[erich@localhost erich]$ cat test.xml
<hello><world></world></hello>
[erich@localhost erich]$ ilrun Crash.exe http://10.1.1.11/test.xml
0
1
2
3
4
Segmentation fault
[erich@localhost erich]$ ilrun Crash.exe test.xml
0
1
2
3
4
5
6
...
99
[erich@localhost erich]$
|
Wed 19 Jan 2005 05:26:55 PM UTC, comment #4:
Stephen Compall: I did my own build, with default options. Where can I find your rpms?
All: Sorry, my example (Test.cs) was too simple, I can't reproduce the bug now. Maybe I was fooled by the segfault inside gdb... Anyway, I'm sure there is such a problem, maybe in more difficult cases (garbage collection?)
In my real-world program, the program segfaults (most likely during garbage collection); if I add the following few lines in cvm_call.c, it works:
--- cvm_call.c 2005-01-19 18:07:25.282411440 +0100
+++ cvm_call_orig.c 2005-01-19 18:04:39.228655448 +0100
@@ -928,12 +928,6 @@
{
/* Call a virtual method */
tempptr = stacktop[-((ILInt32)CVM_ARG_DWIDE1_SMALL)].ptrValue;
-
- /* ERICH quickhack */
- if (tempptr == NULL) {
- NULL_POINTER_EXCEPTION();
- }
-
BEGIN_NULL_CHECK(tempptr)
{
/* Locate the method to be called */
Obviously this should be obsolete when using the signal-based BEGIN_NULL_CHECK...
The same program worked fine on Mandrake 9.1 (Kernel 2.4.x)...
|
Tue 18 Jan 2005 01:37:05 AM UTC, original submission:
In StreamWriter.Dispose(bool disposing), stream.Flush() is called. Unfortunately, HttpStream is already disposed, so "underlying" is already null. HttpStream.Flush() simply calls underlying.Flush(), so this should IMO throw a NullReferenceException. But, even more unfortunately, the virtual machine crashes with a segmentation violation, in cvm_call.c line 934, since tempptr is a null pointer.
|