Re: GNAT Spitbol segmentation fault

["Alex R. Mosteo" <devnull@mailinator.com>]

Alex R. Mosteo wrote:

> Jeffrey Creem wrote:
> 
>> Alex R. Mosteo wrote:
>>> Hello,
>>> 
>>> before filing a bug report I'd like to hear your opinion to rule out a
>>> mistake on my part. I'm using the excellent Gnat.Spitbol.Patterns
>>> package to extract some patterns from large bodies of text. I'm doing it
>>> with this scheme:
>>> 
>>> declare
>>>    Text   : aliased Vstring := <initial text>;
>>>    Target : aliased Vstring;
>>>    
>>>    Patt   : constant Pattern := Some_Patterns ** Target;
>>> begin
>>>    while Match (Text, Target, "") loop
>>>       --  This extracts a Target string and removes it from the text.
>>>       --  It doesn't matter if the surrounding text causes new
>>>       aftermatches. Do_Something_With (Target);
>>>    end loop;
>>> end;
>>> 
>>> Very rarely I get a Storage_Error and segment violation that kills the
>>> program. Running inside gdb I get this backtrace:
>>> 
>>> #0  0xb7ddf37c in memcpy () from /lib/tls/i686/cmov/libc.so.6
>>> #1  0x081b7d8d in ada.strings.fixed.replace_slice ()
>>> #2  0x081bd6cf in ada.strings.unbounded.replace_slice ()
>>> #3  0x081d4f5e in gnat.spitbol.patterns.match ()
>>> 
>>> Unfortunately, address2line doesn't make any valid source lines from
>>> these addresses, I suppose because the gdb wrapping (but this is just a
>>> guess).
>>> 
>>> If you have used Gnat Spitbol before, could you comment if I'm doing
>>> something risky? This is with gnat gpl 2006 in linux x86
>>> 
>>> 
>> 
>> Any chance this is a simple matter of blowing the stack someplace?
>> Compile with -fstack-check and/or try increasing the stack space of the
>> task that is doing this work.
> 
> I'm already compiling with it, but it's true that it isn't 100% reliable
> so it's worth a try. The spitbol package also checks some internal stack,
> but perhaps its size is larger than the default for tasks.

FYI, in the end, I think it was a stack fault: I've pinpointed the problem
to large unbounded_strings (where large is larger than stack size). Coupled
with what Simon said about the GNAT runtime not being compiled with -g, I
guess it neither uses --fstack-check. So I blame the fault to some internal
conversion to String within the Spitbol code that's overflowing the stack.

I've taken measures to split large strings and haven't yet observed any
problem.

Now I'm being assaulted by doubts about stacks. Doesn't gnat use some
secondary stack for, among other things, strings? Is the size of this stack
also governed by the Storage_Size pragma? Oh well, time to RTFM again...