Re: GNAT Spitbol segmentation fault

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

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.