bugDotGNU Portable.NET - Bugs: bug #12552, NullReference handling via...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #12552: NullReference handling via interrupts problematic

Submitted by:  Marc Haisenko <darkdust>
Submitted on:  Mon 04 Apr 2005 04:42:40 PM UTC  
 
Category: NoneSeverity: 4 - Important
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

Wed 06 Apr 2005 06:30:32 AM UTC, comment #5:

fixed in cvs

Deryk Robosson <drobosson>
Project Member
Wed 06 Apr 2005 05:01:03 AM UTC, comment #4:

Applied the patch.
Seems to work for me now.
And: had another bug using sockets. When opening and closing connections to an server I had a crash with segfault.
Now I do not have a crash any more.

Plz apply patch in cvs.

Heiko Weiss <brubbel>
Project Member
Tue 05 Apr 2005 02:50:26 PM UTC, comment #3:

> might be the reason for bug 11627, too.


Yes, comment #6 of bug #11627 looks like stack traces I've seen while debugging this bug: stack frames 0, 1 and 2 also were in my stack traces, and the crash is in fact in _ILCVMInterpreter (not surprisingly, it's the main interpreter working horse ;-).

And comment #4 of bug #11627 is also something I've noticed while debugging bug #12323. I then tried to figure out why this guarding null check doesn't work and then stumbled across the interrupt handler and noticed its bug.

I'm adding a comment to bug #11627 for cross reference purposes (I should have become a librarian it seems ;-)

Marc Haisenko <darkdust>
Project Member
Tue 05 Apr 2005 01:46:16 PM UTC, comment #2:

might be the reason for bug 11627, too.

Erich Kitzmüller <ammoq>
Tue 05 Apr 2005 09:13:47 AM UTC, comment #1:

Added patch #3884 which adds --enable/disable-interrupts configure option.

Marc Haisenko <darkdust>
Project Member
Mon 04 Apr 2005 04:42:40 PM UTC, original submission:

I've debugged bug #12323 for a view days now and found out that the real cause of this bug is the handling of null reference checks via interrupts.

Consider the following CVM code fragment which was the culprit of the segfault in bug #12323 (output stems from my debugging code):

0x4215614F: get_static Trumpf.Sys.Diagnostics.TcTrace (0x410458e8)
0x42156154: pread
0x42156155: iread_field 4

The problem here was that pread read the pointer stored at the address returned by get_static and pushed it onto the stack. Unfortunately this was a null pointer and iread_field caused a segmentation fault because the guarding BEGIN_NULL_CHECK was defined to be nothing.

And now to the interrupt handler problem: this segmentation fault is caught the first time we see this code. The signal handler executed a pnet exception handler. But the signal handler never terminates, pnet now runs in the signal handler ! This of course means the next time a segmentation fault happens the system can't call the signal handler (it's still executing) and instead kills the process.

This is what "Advanced UNIX Programming, 2nd edition" says about signal handlers:

===
"Inside the signal handler, you're restricted as to what system calls or standard funcations you can call because the signal may have occurred in a place that can't safely be re-entered. In fact, the SUS (Version 3) defines only 116 so-called async-signal-safe functions, which are listed in Table 9.1."
===

It continues to explain that not even fprintf may be called or safely refer to global variables unless they're of type volatile sig_atomic_t. Obviously, our current signal handler violates this so heavily I'm wondering why this hasn't bitten others earlier :-)

This means we have to work out a new way of how to catch errors via interrupts (which IS quite cheap and speedy). In the mean time I propose disabling the interrupt based checks on POSIX systems by default since it's better to run slow but error-free, IMHO ;-)

Marc Haisenko <darkdust>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Wed 06 Apr 2005 06:30:32 AM UTCdrobossonOpen/ClosedOpen=>Closed
Wed 06 Apr 2005 06:30:31 AM UTCdrobossonStatusNone=>Fixed

Back to the top


Powered by Savane 3.1-cleanup1