GNAT Spitbol segmentation fault

GNAT Spitbol segmentation fault

[Alex R. Mosteo]

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

Re: GNAT Spitbol segmentation fault

[Jeffrey Creem]

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.

Re: GNAT Spitbol segmentation fault

[Georg Bauhaus]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]

On Thu, 2007-01-18 at 13:33 +0100, 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;

An ad hoc: I ran into trouble when forgetting to initialize
unbounded strings to the null string. Nul in the case of Target,
I think.

>    
>    Patt   : constant Pattern := Some_Patterns ** Target;
> begin
>    while Match (Text, Target, "") loop
                        Patt ?
>       --  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;


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: GNAT Spitbol segmentation fault

[Alex R. Mosteo]

Georg Bauhaus wrote:

> On Thu, 2007-01-18 at 13:33 +0100, 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;
> 
> An ad hoc: I ran into trouble when forgetting to initialize
> unbounded strings to the null string. Nul in the case of Target,
> I think.

Thanks, I'll add it.

> 
>>    
>>    Patt   : constant Pattern := Some_Patterns ** Target;
>> begin
>>    while Match (Text, Target, "") loop
>                         Patt ?

Of course you're right.

>>       --  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;

Re: GNAT Spitbol segmentation fault

[Alex R. Mosteo]

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.

Re: GNAT Spitbol segmentation fault

[Simon Wright]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> 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).

For reasons I don't understand the GNAT runtime is compiled without
-g.

You could rebuild the RTL (there is a script to do so in the adalib
directory, I think -- yes, Makefile.adalib -- not always completely
straightforward to use IME but usually possible!).

Re: GNAT Spitbol segmentation fault

[Alex R. Mosteo]

Simon Wright wrote:

> "Alex R. Mosteo" <devnull@mailinator.com> writes:
> 
>> 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).
> 
> For reasons I don't understand the GNAT runtime is compiled without
> -g.

Ah, I see, that's the reason.

> You could rebuild the RTL (there is a script to do so in the adalib
> directory, I think -- yes, Makefile.adalib -- not always completely
> straightforward to use IME but usually possible!).

The error happens so rarely that I have more pressing matters, but I'll try
if I come to it.

Thanks for all the suggestions,

A. Mosteo.

Re: GNAT Spitbol segmentation fault

[Alex R. Mosteo]

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...