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

[Jeffrey Creem]

Post by 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
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
#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.

[Alex R. Mosteo]

Post by Jeffrey Creem

Post by 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
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
#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.

[Alex R. Mosteo]

Post by Alex R. Mosteo

Post by Jeffrey Creem

Post by 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
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
#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...

[Georg Bauhaus]

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

Post by Alex R. Mosteo
Patt : constant Pattern := Some_Patterns ** Target;
begin
while Match (Text, Target, "") loop

Patt ?

Post by Alex R. Mosteo
-- 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;

[Alex R. Mosteo]

Post by Georg Bauhaus

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

Post by Georg Bauhaus

Post by Alex R. Mosteo
Patt : constant Pattern := Some_Patterns ** Target;
begin
while Match (Text, Target, "") loop

Patt ?

Of course you're right.

Post by Georg Bauhaus

Post by Alex R. Mosteo
-- 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;

[Simon Wright]

Post by Alex R. Mosteo
Very rarely I get a Storage_Error and segment violation that kills
#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!).

[Alex R. Mosteo]

Post by Simon Wright

Post by Alex R. Mosteo
Very rarely I get a Storage_Error and segment violation that kills
#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.

Post by Simon Wright
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.