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

Submitter:  Marc Haisenko <darkdust>
Submitted:  Mon 04 Apr 2005 04:42:40 PM UTC
   
 
Category:  None Severity:  4 - Important
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

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

fixed in cvs

Deryk Robosson <drobosson>
Group 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>
Group 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>
Group 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>
Group 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>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 2 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-04-06 drobosson Open/ClosedOpen Closed
2005-04-06 drobosson StatusNone Fixed

Back to the top

Powered by Savane 3.13-02a9.
Corresponding source code