signal SIGSEGV, Segmentation fault

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

signal SIGSEGV, Segmentation fault

Andreas Höschler
Hi all,

I am testing one of my apps out on the recent GNUstep tree I managed to get to work on Ubuntu 16.04 in the meanwhile. I already got relatively far with a few minor tweaks (replacing deprecated methods,...). However, I got stuck at one point and have no idea how to proceed from here! :-(

I have a subclass

MapView : ESMMapView : GSImageView : NSImageView

with 

@interface MapView : ESMMapView //FBMapView
{
   NSPoint _currentPosition;
   NSTimer *_routeFadeTimer;
   float _positionAlpha;
   BOOL _addAlpha;
   NSString *_message;

   NSArray *_routeNodes;
   NSBezierPath *_routePath;

   NSArray *_departurePaths;
   NSArray *_arrivalPaths;
   NSArray *_overlayPaths;
      
   BOOL _routeVisible;
   BOOL _departurePathVisible;
   BOOL _arrivalPathVisible;
}

and

@interface ESMMapView : GSImageView  
{   
   BOOL _osmDrawing;
   BOOL _drawPrimaryInLays;
   BOOL _drawOtherInLays;
   NSRect _visibleMapSection;
   float _heightOfVisibleMapInKm;
   NSMutableArray *_labels;
   NSArray *_bezierPathsForLand;   
   NSData *_shapeData;
   
   @public   
   NSMutableArray *_rectObjects;   // make sure labels do not overlap
   NSMutableArray *_mapPaths;     // for each kind one, unless we are in detailed mode
   NSMutableArray *_mapShields;  // "A1", B 203",...
   NSMutableArray *_mapLabels;   // lables like "Bad Oldesloe", "AS Reinfeld", "Bahnhof",...
   NSMutableArray *_mapLocs;      // Polter, Companies,...
   NSMutableArray *_mapLines;     // routes
}


I get a 

Thread 1 "TimberNav" received signal SIGSEGV, Segmentation fault.
-[MapView drawRect:] (self=0xb7ca746e <-[NSView displayRectIgnoringOpacity:inContext:]+318>,
    _cmd=0x8a704b8, rect=...) at MapView.m:168
168           NSLog(@"routeVisible: %d", _routeVisible);
(gdb)

when running the app in gdb and simply a

Segmentation fault

when running the app directly. This happens in the MapView::drawRect method

- (void)drawRect:(NSRect)rect
{
   NSLog(@"MapView drawRect %@ ... _osmDrawing %d", NSStringFromRect(rect), _osmDrawing);
   [super drawRect:rect];
   NSLog(@"After super drawRect:rect");
   [self bums];
   //   if (image != nil && _osmDrawing == NO)
     {
      NSImage *image = [self image];
      NSSize imageSize = [image size];
      
      // draw route
      NSLog(@"routeVisible: %d", _routeVisible);  // <-- this causes the SIGSEGV
      NSLog(@"routePath: %@", _routePath);
      
      if (_routeVisible && _routePath != nil)
        {
         [[NSColor purpleColor] set];
         
         [_routePath setLineWidth:8];
         [_routePath stroke];
        }
    ...
}

while accessing one of its instance variables, actually in the 

      NSLog(@"routeVisible: %d", _routeVisible);

line. When I comment this line out I get the same error in the next line while accessing _routePath and so on. I am clueless how to fix this. The code works on MacOSX and also with on an ancient GNUstep/Debian/Kubuntu setup. Any idea what might cause this trouble on Ubuntu 16.04 with the latest GNUstep or how to further track this down?

Thanks a lot in advance!!

Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Josh Freeman
Hi Andreas,

On May 3, 2018, at 2:45 PM, Andreas Höschler wrote:

> Segmentation fault
> ...
> while accessing one of its instance variables, actually in the
>
>       NSLog(@"routeVisible: %d", _routeVisible);
>
> line. When I comment this line out I get the same error in the next  
> line while accessing _routePath and so on. I am clueless how to fix  
> this. The code works on MacOSX and also with on an ancient GNUstep/
> Debian/Kubuntu setup. Any idea what might cause this trouble on  
> Ubuntu 16.04 with the latest GNUstep or how to further track this  
> down?


    Currently, libobjc2's non-fragile ABI can cause segfaults on  
Debian-based distros (& perhaps other Linux distros) when directly  
accessing some class' instance variables.

    There's a few workarounds for Ubuntu:

* The Ubuntu install script on the wiki has a workaround (it checks  
out an old version of GNUstep-make that builds using the fragile ABI):
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux

* If you need the non-fragile ABI, there's a script + objc2-patch  
attached to this list message:
http://lists.gnu.org/archive/html/discuss-gnustep/2017-12/msg00129.html

* David is working on a new ABI, and you can try his experimental  
builds:
http://lists.gnu.org/archive/html/gnustep-dev/2018-04/msg00051.html

Cheers,

Josh


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Riccardo Mottola-5
In reply to this post by Andreas Höschler
Hi Andreas,

Andreas Höschler wrote:
> I am testing one of my apps out on the recent GNUstep tree I managed
> to get to work on Ubuntu 16.04 in the meanwhile. I already got
> relatively far with a few minor tweaks (replacing deprecated
> methods,...). However, I got stuck at one point and have no idea how
> to proceed from here! :-(

before banging on the head, since your code is "ancient" could you try
using gcc and its runtime if you are using clang+libobjc2.

This would mean however probably compiling all gnustep yourself.

Riccardo

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Andreas Höschler
Hi Riccardo,

before banging on the head, since your code is "ancient" could you try using gcc and its runtime if you are using clang+libobjc2.

This would mean however probably compiling all gnustep yourself.

1) I have built GNustep on my own
2) I am using gcc and its runtime

!?? That's what presented me the app with the unexplainable segmentation fault!?

Any idea?

Thanks,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Fred Kiefer
Am 07.05.2018 um 19:45 schrieb Andreas Höschler <[hidden email]>:

>
>> before banging on the head, since your code is "ancient" could you try using gcc and its runtime if you are using clang+libobjc2.
>>
>> This would mean however probably compiling all gnustep yourself.
>
> 1) I have built GNustep on my own
> 2) I am using gcc and its runtime
>
> !?? That's what presented me the app with the unexplainable segmentation fault!?
>
> Any idea?

Thank you for clarifying that you use gcc.

Could it be that self gets deallocated in the "bums" method call? The best way to find out about this would be to run the application with valgrind. Many mysterious problems became quite clear when looking at them through the valgrind toolset. If you require help with that, I could provide you with detailed instructions.
_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Andreas Höschler

On 07 May 2018, at 23:16, Fred Kiefer <[hidden email]> wrote:

1) I have built GNustep on my own
2) I am using gcc and its runtime

!?? That's what presented me the app with the unexplainable segmentation fault!?

Any idea?

Thank you for clarifying that you use gcc.

Could it be that self gets deallocated in the "bums" method call?

No! The bums call is just for logging and breakpoint purposes. The method just longs out @"bums":

NSLog(@"bums");

The best way to find out about this would be to run the application with valgrind. Many mysterious problems became quite clear when looking at them through the valgrind toolset. If you require help with that, I could provide you with detailed instructions.

I will probably need help with that. :-) How would I start?

Thanks a lot,

  Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Fred Kiefer


> Am 08.05.2018 um 11:27 schrieb Andreas Höschler <[hidden email]>:
>
>
>> On 07 May 2018, at 23:16, Fred Kiefer <[hidden email]> wrote:
>
>> The best way to find out about this would be to run the application with valgrind. Many mysterious problems became quite clear when looking at them through the valgrind toolset. If you require help with that, I could provide you with detailed instructions.
>
> I will probably need help with that. :-) How would I start?

That is a simple three steps process:

- Get and install valgrind  (sudo apt-get install valgrind)

- Start your application with valgrind (valgrind Ink.app/Ink)

- Be very patient, use your application as usual and watch the messages scroll by in the console.


And when the segmentation vault happens valgrind will be able to tell you what caused it.
_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Andreas Fink-2
or run the binary with lldb and set a breakpoint at [NSException raise] to catch any exceptions thrown.

break set -S raise

Once you get the crash, you end up in lldb debugger and can issue "bt" for backtrace and you see exactly where you are.


> On 8 May 2018, at 19:35, Fred Kiefer <[hidden email]> wrote:
>
>
>
>> Am 08.05.2018 um 11:27 schrieb Andreas Höschler <[hidden email]>:
>>
>>
>>> On 07 May 2018, at 23:16, Fred Kiefer <[hidden email]> wrote:
>>
>>> The best way to find out about this would be to run the application with valgrind. Many mysterious problems became quite clear when looking at them through the valgrind toolset. If you require help with that, I could provide you with detailed instructions.
>>
>> I will probably need help with that. :-) How would I start?
>
> That is a simple three steps process:
>
> - Get and install valgrind  (sudo apt-get install valgrind)
>
> - Start your application with valgrind (valgrind Ink.app/Ink)
>
> - Be very patient, use your application as usual and watch the messages scroll by in the console.
>
>
> And when the segmentation vault happens valgrind will be able to tell you what caused it.
> _______________________________________________
> Discuss-gnustep mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Andreas Höschler
In reply to this post by Fred Kiefer
Hi Fred and all,

The best way to find out about this would be to run the application with valgrind. Many mysterious problems became quite clear when looking at them through the valgrind toolset. If you require help with that, I could provide you with detailed instructions.

I will probably need help with that. :-) How would I start?

That is a simple three steps process:

- Get and install valgrind  (sudo apt-get install valgrind)

- Start your application with valgrind (valgrind Ink.app/Ink)

- Be very patient, use your application as usual and watch the messages scroll by in the console.

And when the segmentation vault happens valgrind will be able to tell you what caused it.

Thanks for the hint. valgrind reports 


2018-05-22 11:23:16.323 TimberNav[7685:7685] MapView drawRect {x = 0; y = 0; width = 817; height = 334} ... _osmDrawing 0
2018-05-22 11:23:16.327 TimberNav[7685:7685] After super drawRect:rect
2018-05-22 11:23:16.328 TimberNav[7685:7685] bums
==7685== Use of uninitialised value of size 4
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==
==7685== Invalid write of size 1
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==  Address 0x134 is not stack'd, malloc'd or (recently) free'd
==7685==
==7685==
==7685== Process terminating with default action of signal 11 (SIGSEGV)
==7685==  Access not within mapped region at address 0x134
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==  If you believe this happened as a result of a stack
==7685==  overflow in your program's main thread (unlikely but
==7685==  possible), you can try to increase the size of the
==7685==  main thread stack using the --main-stacksize= flag.
==7685==  The main thread stack size used in this run was 8388608.
==7685==
==7685== HEAP SUMMARY:
==7685==     in use at exit: 7,671,140 bytes in 99,510 blocks
==7685==   total heap usage: 345,414 allocs, 245,904 frees, 38,473,207 bytes allocated
==7685==
==7685== LEAK SUMMARY:
==7685==    definitely lost: 49,171 bytes in 1,041 blocks
==7685==    indirectly lost: 457,010 bytes in 8,088 blocks
==7685==      possibly lost: 3,449,433 bytes in 46,039 blocks
==7685==    still reachable: 3,715,526 bytes in 44,342 blocks
==7685==                       of which reachable via heuristic:
==7685==                         newarray           : 69,036 bytes in 303 blocks
==7685==         suppressed: 0 bytes in 0 blocks
==7685== Rerun with --leak-check=full to see details of leaked memory
==7685==
==7685== For counts of detected and suppressed errors, rerun with: -v
==7685== Use --track-origins=yes to see where uninitialised values come from
==7685== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)
==7685== Use of uninitialised value of size 4
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==
==7685== Invalid write of size 1
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==  Address 0x134 is not stack'd, malloc'd or (recently) free'd
==7685==
==7685==
==7685== Process terminating with default action of signal 11 (SIGSEGV)
==7685==  Access not within mapped region at address 0x134
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==  If you believe this happened as a result of a stack
==7685==  overflow in your program's main thread (unlikely but
==7685==  possible), you can try to increase the size of the
==7685==  main thread stack using the --main-stacksize= flag.
==7685==  The main thread stack size used in this run was 8388608.
==7685==
==7685== HEAP SUMMARY:
==7685==     in use at exit: 7,671,140 bytes in 99,510 blocks
==7685==   total heap usage: 345,414 allocs, 245,904 frees, 38,473,207 bytes allocated
==7685==
==7685== LEAK SUMMARY:
==7685==    definitely lost: 49,171 bytes in 1,041 blocks
==7685==    indirectly lost: 457,010 bytes in 8,088 blocks
==7685==      possibly lost: 3,449,433 bytes in 46,039 blocks
==7685==    still reachable: 3,715,526 bytes in 44,342 blocks
==7685==                       of which reachable via heuristic:
==7685==                         newarray           : 69,036 bytes in 303 blocks
==7685==         suppressed: 0 bytes in 0 blocks
==7685== Rerun with --leak-check=full to see details of leaked memory
==7685==
==7685== For counts of detected and suppressed errors, rerun with: -v
==7685== Use --track-origins=yes to see where uninitialised values come from
==7685== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)

- (void)drawRect:(NSRect)rect
{
   NSLog(@"MapView drawRect %@ ... _osmDrawing %d", NSStringFromRect(rect), _osmDrawing);
   [super drawRect:rect];
   NSLog(@"After super drawRect:rect");
   [self bums];
   //   if (image != nil && _osmDrawing == NO)
     {
      NSImage *image = [self image];
      NSSize imageSize = [image size];
      
      _routeVisible = YES;    // <--- this sis line 168
      // draw route
      NSLog(@"routeVisible: %d", _routeVisible);
      NSLog(@"routePath: %@", _routePath);
      ...
}


I am accessing a BOOL ivar of MapView in the line that crashes the app.

MapView : ESMMapView : GSImageView : NSImageView

MapView is a subclass of NSImageView (see above inheritance string). Each subclass adds properties, some are public.

@interface MapView : ESMMapView
{
   NSPoint _currentPosition;
   NSTimer *_routeFadeTimer;
   float _positionAlpha;
   BOOL _addAlpha;
   NSString *_message;

   NSArray *_routeNodes;
   NSBezierPath *_routePath;

   NSArray *_departurePaths;
   NSArray *_arrivalPaths;
   NSArray *_overlayPaths;
      
   BOOL _routeVisible;
   BOOL _departurePathVisible;
   BOOL _arrivalPathVisible;
}

The code works great under MacOSX and also worked under the old GNUstep/debian system. On Ubuntu with current GNUstep it fails.

Any further ideas?

Thanks a lot,

 Andreas




_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Wolfgang Lux
Am 22.05.2018 um 11:31 schrieb Andreas Höschler <[hidden email]>:

> Any further ideas?

Looking back at your initial report, it has this telling line about the crash:

Thread 1 "TimberNav" received signal SIGSEGV, Segmentation fault.
-[MapView drawRect:] (self=0xb7ca746e <-[NSView displayRectIgnoringOpacity:inContext:]+318>,
    _cmd=0x8a704b8, rect=...) at MapView.m:168
168           NSLog(@"routeVisible: %d", _routeVisible);
(gdb)

The self parameter in the call is a pointer into the code area of the program. So it looks like a serious memory management issue in your program where the MapView object that you intended to call the drawRect: method on has been released already and its memory been overwritten by some other code.

Perhaps adding NSZombieEnabled=YES to the environment before running your program might already give you a clue.

Wolfgang
_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Andreas Höschler
Hi Wolfgang,

Any further ideas?

Looking back at your initial report, it has this telling line about the crash:

Thread 1 "TimberNav" received signal SIGSEGV, Segmentation fault.
-[MapView drawRect:] (self=0xb7ca746e <-[NSView displayRectIgnoringOpacity:inContext:]+318>,
   _cmd=0x8a704b8, rect=...) at MapView.m:168
168           NSLog(@"routeVisible: %d", _routeVisible);
(gdb)

The self parameter in the call is a pointer into the code area of the program. So it looks like a serious memory management issue in your program where the MapView object that you intended to call the drawRect: method on has been released already and its memory been overwritten by some other code.

How do you see that the self pointer points to code area?

I have added a retain in the init method of MapView (dirty hack)

- (id)initWithFrame:(NSRect)frameRect
{
   NSLog(@"initWithFrame ...");
   self = [super initWithFrame: frameRect];
   [self retain];
   ...
}

to check your proposition and also did

- (void)dealloc
{
   NSLog(@"MapView dealloc");
   ...
   [super dealloc];
}

This changed nothing. The program still crashes at the same spot and MapView is never deallocated (at least dealloc not called)!? And remember, the app works perfectly well in two other environments (for whatever that's worth). 

Perhaps adding NSZombieEnabled=YES to the environment before running your program might already give you a clue.

You mean

export NSZombieEnabled=YES
openapp <application>

?

Thanks,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Wolfgang Lux


> Am 22.05.2018 um 13:54 schrieb Andreas Höschler <[hidden email]>:
>
> Hi Wolfgang,
>
>>> Any further ideas?
>>
>> Looking back at your initial report, it has this telling line about the crash:
>>
>> Thread 1 "TimberNav" received signal SIGSEGV, Segmentation fault.
>> -[MapView drawRect:] (self=0xb7ca746e <-[NSView displayRectIgnoringOpacity:inContext:]+318>,
>>    _cmd=0x8a704b8, rect=...) at MapView.m:168
>> 168           NSLog(@"routeVisible: %d", _routeVisible);
>> (gdb)
>>
>> The self parameter in the call is a pointer into the code area of the program. So it looks like a serious memory management issue in your program where the MapView object that you intended to call the drawRect: method on has been released already and its memory been overwritten by some other code.
>
> How do you see that the self pointer points to code area?

From the self pointer in the call frame:
  self=0xb7ca746e <-[NSView displayRectIgnoringOpacity:inContext:]+318>
gdb resolves this address to an address in the code of the displayRectIgnoringOpacity:inContext: method from the NSView class. :-)

> I have added a retain in the init method of MapView (dirty hack)
>
> - (id)initWithFrame:(NSRect)frameRect
> {
>    NSLog(@"initWithFrame ...");
>    self = [super initWithFrame: frameRect];
>    [self retain];
>    ...
> }
>
> to check your proposition and also did
>
> - (void)dealloc
> {
>    NSLog(@"MapView dealloc");
>    ...
>    [super dealloc];
> }
>
> This changed nothing. The program still crashes at the same spot and MapView is never deallocated (at least dealloc not called)!? And remember, the app works perfectly well in two other environments (for whatever that's worth).

With the same version of gnustep-base and gnustep-gui?

> Perhaps adding NSZombieEnabled=YES to the environment before running your program might already give you a clue.
>
> You mean
>
> export NSZombieEnabled=YES
> openapp <application>

Yes.

Wolfgang



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Andreas Höschler
Hi Wolfgang,

From the self pointer in the call frame:
 self=0xb7ca746e <-[NSView displayRectIgnoringOpacity:inContext:]+318>
gdb resolves this address to an address in the code of the displayRectIgnoringOpacity:inContext: method from the NSView class. :-)

Aha, interesting. But this still rings no bell (no idea how this could be).

This changed nothing. The program still crashes at the same spot and MapView is never deallocated (at least dealloc not called)!? And remember, the app works perfectly well in two other environments (for whatever that's worth).

With the same version of gnustep-base and gnustep-gui?

No, with current MacOSX and ancient GNUstep sources I was using so far on Solaris and Debian 

I am now trying current GNUstep sources on Ubuntu 16, so almost everything has changed: gcc, objc, GNUstep, OS,... :-(

Thanks,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Andreas Höschler
Hi all,

I just added

- (void)drawRect:(NSRect)rect
{
   NSLog(@"MapView drawRect %@ ... _osmDrawing %d", NSStringFromRect(rect), _osmDrawing);
   [super drawRect:rect];
   NSLog(@"After super drawRect:rect");

      NSImage *image = [self image];
      NSSize imageSize = [image size];
      
      NSLog(@"asasa %@", self);  // <--- this line

      NSLog(@"routeVisible: %d", _routeVisible);
      NSLog(@"routePath: %@", _routePath);

}

and get

2018-05-22 14:32:37.291 TimberNav[10763:10763] MapView drawRect {x = 0; y = 0; width = 817; height = 334} ... _osmDrawing 0
2018-05-22 14:32:37.291 TimberNav[10763:10763] After super drawRect:rect
2018-05-22 14:32:37.291 TimberNav[10763:10763] bums
2018-05-22 14:32:37.291 TimberNav[10763:10763] asasa (null)

before the app crshes while accessing the ivar _routeVisible. So what does that mean? This looks like a very serious issue with the OS, gcc, objc to me!? 

This brings me back to the question of a reliably working Linux, GNUstep combo? If I could I would revert back to my ancient GNUstep tree (that worked at least) but the ancient GNUwtep sources do no longer build on Ubuntu which leaves me in a void. :-(

Best wishes,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Richard Frith-Macdonald-9
In reply to this post by Andreas Höschler


> On 22 May 2018, at 13:09, Andreas Höschler <[hidden email]> wrote:
>
> Hi Wolfgang,
>
>> From the self pointer in the call frame:
>>  self=0xb7ca746e <-[NSView displayRectIgnoringOpacity:inContext:]+318>
>> gdb resolves this address to an address in the code of the displayRectIgnoringOpacity:inContext: method from the NSView class. :-)
>
> Aha, interesting. But this still rings no bell (no idea how this could be).

Well, anything that overwrite the memory location in which 'self' is stored could cause this.
The most common thing (as suggested by Wolfgang) would be if the object was deallocated and the memory re-used (a retain/release error), but buffer overruns could also corrupt the memory.
Fred's suggestion of running under valgrind should help find the problem in either case.


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Andreas Höschler
Hi Richard,

Aha, interesting. But this still rings no bell (no idea how this could be).

Well, anything that overwrite the memory location in which 'self' is stored could cause this.
The most common thing (as suggested by Wolfgang) would be if the object was deallocated and the memory re-used (a retain/release error),

The object is not deallocated as I have shown with a log message in -dealloc. 

but buffer overruns could also corrupt the memory.
Fred's suggestion of running under valgrind should help find the problem in either case.

This gave me nothing (see below).

valgrind reports


2018-05-22 11:23:16.323 TimberNav[7685:7685] MapView drawRect {x = 0; y = 0; width = 817; height = 334} ... _osmDrawing 0
2018-05-22 11:23:16.327 TimberNav[7685:7685] After super drawRect:rect
2018-05-22 11:23:16.328 TimberNav[7685:7685] bums
==7685== Use of uninitialised value of size 4
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==
==7685== Invalid write of size 1
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==  Address 0x134 is not stack'd, malloc'd or (recently) free'd
==7685==
==7685==
==7685== Process terminating with default action of signal 11 (SIGSEGV)
==7685==  Access not within mapped region at address 0x134
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==  If you believe this happened as a result of a stack
==7685==  overflow in your program's main thread (unlikely but
==7685==  possible), you can try to increase the size of the
==7685==  main thread stack using the --main-stacksize= flag.
==7685==  The main thread stack size used in this run was 8388608.
==7685==
==7685== HEAP SUMMARY:
==7685==     in use at exit: 7,671,140 bytes in 99,510 blocks
==7685==   total heap usage: 345,414 allocs, 245,904 frees, 38,473,207 bytes allocated
==7685==
==7685== LEAK SUMMARY:
==7685==    definitely lost: 49,171 bytes in 1,041 blocks
==7685==    indirectly lost: 457,010 bytes in 8,088 blocks
==7685==      possibly lost: 3,449,433 bytes in 46,039 blocks
==7685==    still reachable: 3,715,526 bytes in 44,342 blocks
==7685==                       of which reachable via heuristic:
==7685==                         newarray           : 69,036 bytes in 303 blocks
==7685==         suppressed: 0 bytes in 0 blocks
==7685== Rerun with --leak-check=full to see details of leaked memory
==7685==
==7685== For counts of detected and suppressed errors, rerun with: -v
==7685== Use --track-origins=yes to see where uninitialised values come from
==7685== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)
==7685== Use of uninitialised value of size 4
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==
==7685== Invalid write of size 1
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==  Address 0x134 is not stack'd, malloc'd or (recently) free'd
==7685==
==7685==
==7685== Process terminating with default action of signal 11 (SIGSEGV)
==7685==  Access not within mapped region at address 0x134
==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
==7685==    by 0xBEAD8617: ???
==7685==  If you believe this happened as a result of a stack
==7685==  overflow in your program's main thread (unlikely but
==7685==  possible), you can try to increase the size of the
==7685==  main thread stack using the --main-stacksize= flag.
==7685==  The main thread stack size used in this run was 8388608.
==7685==
==7685== HEAP SUMMARY:
==7685==     in use at exit: 7,671,140 bytes in 99,510 blocks
==7685==   total heap usage: 345,414 allocs, 245,904 frees, 38,473,207 bytes allocated
==7685==
==7685== LEAK SUMMARY:
==7685==    definitely lost: 49,171 bytes in 1,041 blocks
==7685==    indirectly lost: 457,010 bytes in 8,088 blocks
==7685==      possibly lost: 3,449,433 bytes in 46,039 blocks
==7685==    still reachable: 3,715,526 bytes in 44,342 blocks
==7685==                       of which reachable via heuristic:
==7685==                         newarray           : 69,036 bytes in 303 blocks
==7685==         suppressed: 0 bytes in 0 blocks
==7685== Rerun with --leak-check=full to see details of leaked memory
==7685==
==7685== For counts of detected and suppressed errors, rerun with: -v
==7685== Use --track-origins=yes to see where uninitialised values come from
==7685== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)

- (void)drawRect:(NSRect)rect
{
   NSLog(@"MapView drawRect %@ ... _osmDrawing %d", NSStringFromRect(rect), _osmDrawing);
   [super drawRect:rect];
   NSLog(@"After super drawRect:rect");
   [self bums];
   //   if (image != nil && _osmDrawing == NO)
     {
      NSImage *image = [self image];
      NSSize imageSize = [image size];
      
      _routeVisible = YES;    // <--- this is line 168
      // draw route
      NSLog(@"routeVisible: %d", _routeVisible);
      NSLog(@"routePath: %@", _routePath);
      ...
}

Thanks,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Riccardo Mottola-5
In reply to this post by Andreas Höschler
Hi,

Andreas Höschler wrote:

>
> 2018-05-22 14:32:37.291 TimberNav[10763:10763] MapView drawRect {x =
> 0; y = 0; width = 817; height = 334} ... _osmDrawing 0
> 2018-05-22 14:32:37.291 TimberNav[10763:10763] After super drawRect:rect
> 2018-05-22 14:32:37.291 TimberNav[10763:10763] bums
> 2018-05-22 14:32:37.291 TimberNav[10763:10763] asasa (null)
>
> before the app crshes while accessing the ivar _routeVisible. So what
> does that mean? This looks like a very serious issue with the OS, gcc,
> objc to me!?

where does bums come from?
It looks really strange that self is null.

I would look up the alloc/init chain to check if somewhere an init
return nil for some error.


>
> This brings me back to the question of a reliably working Linux,
> GNUstep combo? If I could I would revert back to my ancient GNUstep
> tree (that worked at least) but the ancient GNUwtep sources do no
> longer build on Ubuntu which leaves me in a void. :-(

GCC/Linux works fine, I test it in a lot of places.
Specifically, Ubuntu LTS/GCC/Linux work fine for me on x86 on every
application I tried on. I am away for work for a week, on my retour I
can give you exact configuration details.

To me it really smells that your custom app has some kind of issue I
can't spot or triggers a strange GNUstep behaviour.
Did you try running other application and "stress" your environment a
bit? Try from simple Ink to using Terminal and GWorkspace. Those will
stress a little bit.

GCC works well for me on most platforms I used, except currently on
FreeBSD where I have strange issues (surely most work is tone there with
clang and libobjc2).

You might want to set up a VM with NetBSD and essential GNUstep
environment to test it, just as a comparison. However, I my "guts" tell
me that it must work just as fine on Ubuntu.

Riccardo
NetBSD and OpenBSD are very reliable for me with GCC.

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Richard Frith-Macdonald-9
In reply to this post by Andreas Höschler


> On 22 May 2018, at 13:55, Andreas Höschler <[hidden email]> wrote:
>
> Hi Richard,
>
>>> Aha, interesting. But this still rings no bell (no idea how this could be).
>>
>> Well, anything that overwrite the memory location in which 'self' is stored could cause this.
>> The most common thing (as suggested by Wolfgang) would be if the object was deallocated and the memory re-used (a retain/release error),
>
> The object is not deallocated as I have shown with a log message in -dealloc.
>
>> but buffer overruns could also corrupt the memory.
>> Fred's suggestion of running under valgrind should help find the problem in either case.
>
> This gave me nothing (see below).
>
> valgrind reports
>
>
> 2018-05-22 11:23:16.323 TimberNav[7685:7685] MapView drawRect {x = 0; y = 0; width = 817; height = 334} ... _osmDrawing 0
> 2018-05-22 11:23:16.327 TimberNav[7685:7685] After super drawRect:rect
> 2018-05-22 11:23:16.328 TimberNav[7685:7685] bums
> ==7685== Use of uninitialised value of size 4
> ==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
> ==7685==    by 0xBEAD8617: ???

Well it tells you that some uninitialised value is used at line 168 ...

We already knew that, but I guess the fact that there's no problem reported preceding it means that there's no obvious memory management/corruption issue like a buffer overrun on the heap, and something is specifically setting that location in memory.

You might need to actively debug the program to find out what's going on ... use gdb to break at the start ofd the method and then step through, instruction by instruction, examining key values to see at what point things change.


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Yavor Doganov-3
In reply to this post by Andreas Höschler
В Tue, 22 May 2018 13:54:08 +0200, Andreas Höschler написа:

> - (id)initWithFrame:(NSRect)frameRect {
>    NSLog(@"initWithFrame ...");
>    self = [super initWithFrame: frameRect];
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    [self retain];
>    ...
> }

Good practice is to check the result of that assignment.  If it fails for
some reason, it would explain (to an extent) why your program crashes
when you attempt to assign a value to the ivar at line 168.  Also, if
self is nil, -retain will do nothing.


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: signal SIGSEGV, Segmentation fault

Riccardo Mottola-5
In reply to this post by Andreas Höschler
Hi Andreas,

are you able to extract a miminal program that uses your MapView class
trimimed down enough so that compiling and running it reproduces the
problem?
I could then test the problem on my system and, as soon as I get back
home, also on my Ubuntu installation.
It could be useful for tracking the error down. Maybe it is x86 vs
amd64. Or gcc version.

Just an Idea, otherwise as Richard you really need to step through.
To track something similar in GNUMail/Pantomime, I had to check every
init/alloc to return "self" and if "self" was initialized. Never use in
init self that was not checked for.
Just a hint.

Riccardo

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
12