Debugging help

[Jan Wielemaker-3]

Hi,

If you are interested in getting better stack management (typically
users of server applications; especially those using the 32-bit
version), please visit http://www.swi-prolog.org/Shifter.html
for a description how you can help debugging.

For now, this is only for people willing to run a C-debugger (gdb) and
compile from the GIT version (pl-devel.git; branch `shift').

In a later stage, I'm certainly interested in other bug reports.
The above page indicates how to find bugs that are easily
reproduced in the development system and fixed.

     Thanks --- Jan

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Roberto Bagnara]

Jan Wielemaker wrote:

> If you are interested in getting better stack management (typically
> users of server applications; especially those using the 32-bit
> version), please visit http://www.swi-prolog.org/Shifter.html
> for a description how you can help debugging.
>
> For now, this is only for people willing to run a C-debugger (gdb) and
> compile from the GIT version (pl-devel.git; branch `shift').
>
> In a later stage, I'm certainly interested in other bug reports.
> The above page indicates how to find bugs that are easily
> reproduced in the development system and fixed.

Hi Jan,

I have read the web page and I wonder if the kind of bug you
are looking for can be statically checked.  I am about to leave
for more than two weeks now, but if you can describe the
property* perhaps I can help.
Cheers,

     Roberto

(*) Something like "no pointer based on a pointer obtained with
     any of some set of functions is passed to any function
     in some other set without doing some operation on it,
     before/after the call".

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@...
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Jan Wielemaker-3]

Hi Roberto,

On Wednesday 21 October 2009 10:33:58 am Roberto Bagnara wrote:

> Jan Wielemaker wrote:
> > If you are interested in getting better stack management (typically
> > users of server applications; especially those using the 32-bit
> > version), please visit http://www.swi-prolog.org/Shifter.html
> > for a description how you can help debugging.
> >
> > For now, this is only for people willing to run a C-debugger (gdb) and
> > compile from the GIT version (pl-devel.git; branch `shift').
> >
> > In a later stage, I'm certainly interested in other bug reports.
> > The above page indicates how to find bugs that are easily
> > reproduced in the development system and fixed.
>
> Hi Jan,
>
> I have read the web page and I wonder if the kind of bug you
> are looking for can be statically checked.  I am about to leave
> for more than two weeks now, but if you can describe the
> property* perhaps I can help.

Yeah, that is (to some extend) possible. Actually I did some of that to
find part of the cases, but unfortunately this approach also finds the
cases that have been `fixed'.

The problem is places where direct pointers are initialised, followed by
something (indirectly) calling garbageCollect() or growStacks(),
followed by usage of this pointer. The fixes vary a bit, often using one
of the schemas below. Here, <reload pointer> means re-initialise it from
something that is relocated by GC/Shift;

    <load pointer>
    <play a bit>
    <something that may call GC>
    <reload pointer>
    ...

or

    <load pointer>
    <play a bit>
    if ( no-space )
    { <make space>
      <reload pointer>
    }
    ...

or

  retry:
    <make mark>
    <load_pointer>
    <call something that may say it is out-of-space>
    if ( no-space )
    { <rewind to mark>
      <make space>
      goto retry;
    }
    ...

So, you really need to check where pointers and loaded and reloaded. My
current code uses call-graph info from GCC (-dr) and a simple
perl-script looking for basic blocks that manipulate pointers and
indirectly calls garbageCollect()/growStacks(). Next a bit of Prolog to
report the source-lines with possibly problematic calls.

I think you should be able to do proper static analysis things using
CIL, but this requires you to be pretty familiar with the CIL framework.
Anyway, if you or someone else wants to dig into it, I'd be very
grateful.

A sensible alternative is to extend the test-suite to deal with all
cases. To some extend, this is doable by running the test-suite using
C-coverage analysis and extend it where needed. The nasty part is the
code using the first `repair' technique: here coverage doesn't mean we
went through this, but it means we went through this code *and* a
shift/gc took place.

A good way to stress the system is running a program that is already doing
a lot in a loop, each time with a little more life-data allocated before
it.  Something like this:

test :-
        length(L, N),
  test,
        is_list(L), % Avoid GC to eat L
        fail,

Tips, tricks and help are still welcome.

        Cheers --- Jan

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog