bugGNUstep - Bugs: bug #30863, Segfault problem on windows (all...

Group
 
 

bug #30863: Segfault problem on windows (all applications) NSTask/thread

Submitter:  Riccardo Mottola <rmottola>
Submitted:  Tue 24 Aug 2010 06:50:01 AM UTC
   
 
Category:  Base/Foundation Severity:  4 - Important
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 01 Sep 2010 09:49:57 PM UTC, comment #8: 

applications no longer crash, seems to be fixed.

Riccardo Mottola <rmottola>
Group Member
Mon 30 Aug 2010 07:29:40 PM UTC, comment #7: 

Should be fixed (svn trunk) to register/unregister the thread when required now.

Richard Frith-Macdonald <CaS>
Group Member
Thu 26 Aug 2010 03:58:50 PM UTC, comment #6: 

We are running into this problem as well in Eggplant.  It's not quite as simple as no pool in place, we tried explicitly adding an NSAutoreleasePool but in our case it's that the code is called before there is a GSCurrentThread() so when it tries to find the pool for the current thread (t) it crashes.

I don't know if the correct solution is to figure out why GSCurrentThread() isn't set/available early enough but possibly a better fix is some protection in + addObject: if GSCurrentThread() returns nil.

Jonathan Gillaspie <jonathanosx>
Group Member
Wed 25 Aug 2010 08:11:22 PM UTC, comment #5: 

Now I understand the problem. Somebody is starting a new thread here and in the called function relies on an autorelease pool, but there wont be any available.
We could now either remove the need for an autorelease pool or add one in this function.
Just removing that one line looks too optimistic to me. We may introduce any amount of race conditions with that change. Better wait until Richard is back.

Fred Kiefer <FredKiefer>
Group Member
Wed 25 Aug 2010 02:19:51 PM UTC, comment #4: 

The autoroelease causing trouble is the one at line 1019 in _threadFunction, the others may be left in.

Riccardo Mottola <rmottola>
Group Member
Wed 25 Aug 2010 01:05:58 PM UTC, comment #3: 

Apapplying the patch pasted below (removing the autoreleases inserted) solves the crash.

Index: Source/NSTask.m
===================================================================
--- Source/NSTask.m     (revisione 31199)
+++ Source/NSTask.m     (copia locale)
@@ -907,7 +907,7 @@
 - (void) _terminatedChild: (int)status
 {
   [tasksLock lock];
-  IF_NO_GC([[self retain] autorelease];)
+//  IF_NO_GC([[self retain] autorelease];)
   NSMapRemove(activeTasks, (void*)(intptr_t)_taskId);
   [tasksLock unlock];
   _terminationStatus = status;
@@ -1019,7 +1019,7 @@
       [tasksLock lock];
       task = (NSConcreteWindowsTask*)NSMapGet(activeTasks,
        (void*)(intptr_t) taskId);
-      IF_NO_GC([[task retain] autorelease];)
+ //     IF_NO_GC([[task retain] autorelease];)
       [tasksLock unlock];
       if (task == nil)
        {
@@ -1358,7 +1358,7 @@
 #if    defined(WAITDEBUG)
              [tasksLock lock];
              t = (NSTask*)NSMapGet(activeTasks, (void*)(intptr_t)result);
-             IF_NO_GC([[t retain] autorelease];)
+//           IF_NO_GC([[t retain] autorelease];)
              [tasksLock unlock];
              if (t != nil)

Riccardo Mottola <rmottola>
Group Member
Wed 25 Aug 2010 09:47:18 AM UTC, comment #2: 

I put a breakpoint in [NSTask finalize] but the application crashes before reaching it.

Riccardo Mottola <rmottola>
Group Member
Tue 24 Aug 2010 08:31:03 AM UTC, comment #1: 

This could be related to Richard's change in NSTask a few days ago. The change 31108 looks basically correct to me. It must be a special case that is causing trouble here.
From your back trace I expect that what is happening is that an NSTask gets freed before the it is removed from the activeTasks map. I don't have an idea how this is possible and it is most certainly a bug somewhere else. But you could try to add a breakpoint in [NSTask finialize] or even try to put the old code back in there:

   [tasksLock lock];
   NSMapRemove(activeTasks, (void*)(intptr_t)_taskId);
   [tasksLock unlock];

Nut more important would be to find out where finalize gets called without the task being properly removed before. We may have to wait for Richard to analyse this.

Fred Kiefer <FredKiefer>
Group Member
Tue 24 Aug 2010 06:50:01 AM UTC, original submission:  

With the latest current, all applications seem to start, display their menus and then crash.
Interestingly, in the debugger for the app GSTest, relaunching the application inside the debugger a second time has it working, here the log:

(gdb) run
Starting program: G:\GNUstep\home\multix\gnustep-cvs\devmodules\usr-apps\example
s\gui\GSTest/GSTest.app/GSTest.exe
[New thread 1672.0xb40]
[New thread 1672.0xb5c]

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 1672.0xb5c]
+[NSAutoreleasePool addObject:] (self=0x704366e0, _cmd=0x70465e28,
    anObj=0x18896d8) at NSAutoreleasePool.m:235
235       pool = t->_autorelease_vars.current_pool;
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: G:\GNUstep\home\multix\gnustep-cvs\devmodules\usr-apps\example
s\gui\GSTest/GSTest.app/GSTest.exe
[New thread 3016.0x102c]

The trace is:

(gdb) bt
#0  +[NSAutoreleasePool addObject:] (self=0x704366e0, _cmd=0x70465e28,
    anObj=0x18896d8) at NSAutoreleasePool.m:235
#1  0x70330486 in -[NSObject autorelease] (self=0x18896d8, _cmd=0x704817f8)
    at NSObject.m:1699
#2  0x703910f8 in _threadFunction (t=0x18896d8) at NSTask.m:1022
#3  0x7c80b729 in KERNEL32!GetModuleFileNameA ()
   from C:\WINDOWS\system32\kernel32.dll
#4  0x00000000 in ?? ()



Riccardo Mottola <rmottola>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by jonathanosx (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by rmottola (Submitted the item)
  •  

    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.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-09-01 rmottola Open/ClosedIn Test Closed
    2010-08-30 CaS StatusNone Fixed
        Open/ClosedOpen In Test
    2010-08-24 FredKiefer CategoryNone Base/Foundation
        Item GroupNone Bug

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code