[mercury-users] Using valgrind --tool=cachegrind with Mercury programs

[Julien Fischer]

Hi Quan,

On Fri, 28 Nov 2008, Quan Phan wrote:

> On Wed, Nov 26, 2008 at 05:27:57PM +0100, Quan Phan wrote:
> Hi Julien,
>
> I've sent this email twice into m-users list but it didn't get through.
> I just resend it now (the nrev program is at the very end).
>
> Sorry if you receive more than one copy. Let me know if you receive it.

Yes, we received it.

> ========================================================================
> Hi Julien,
>
> On Mon, Nov 24, 2008 at 08:38:08PM +1100, Julien Fischer wrote:
>>
>> Hi Quan,
>>
>> On Thu, 20 Nov 2008, Quan Phan wrote:
>>
>>> Hi everybody,
>>>
>>> I tried cachegrind on a normal naive reverse program that works on lists of
>>> integers.
>>> When the list is long enough, I got the following segmentation violation
>>> error. If a list has less than ~350 elements it works fine (the GC
>>> warning is still but no seg faults).
>>
>> Is this with some form of RBMM enabled?
> No, I tried it with asm_fast.gc.
>
>>   Could you post the program?
> I attached nrev.m to this mail.
>
>>> I used rotd 18/11/2008 and the latest valgrind 3.3.1
>>> (but 'valgrind --version' showed 3.2.0-Debian).
>>
>> What order do they occur in your PATH?
> The same errors occurred with the following orders:
> mmc, valgrind, cc 3.4.4 or
> valgrind, mmc, cc 3.4.4
>
> (I installed both of them using this version of C compiler.)

I was referring to the fact that you appear to have two
valgrinds on your system.

>>
>>> Do you know a way I can try to get around it?
>>
>> Does valgrind --tool=memcheck tell you anything more useful?
> Other than several messages on 'uninitialised value', which can be
> suppressed, the last message memcheck reported before the seg fault by
> Mercury itself may give you some clue. This could not be suppressed and
> I could not make much sense out of it yet.
> Trying to read mercury_engine.c w.r.t the error context, it seems the
> Boehm GC interferes with the C stack?!, where temporary locals are
> allocated, when it does collection.

Yes, it does.  The Boehm GC performs all manner of dark magic, most
of which valgrind doesn't like.  It's normal.

> So I tried it with asm_fast.gc.rbmm where the GC is initialized but
> should not do collection. But the same last message was encountered.
> I guessed it might relate to io.write, so I changed nrev.m to not write
> out the resulting list. Then I could only run it with a little bigger
> input (up to ~338) with both asm_fast.gc and asm_fast.gc.rbmm. I had no
> explanation for this.
> I also put the error messages in asm_fast.gc.rbmm below, some of them
> mention the call to GC_push_current_stack, which looks suspicious.

The same thing happens for me when I run it under valgrind.  There is
a problem somewhere, however whether it is us or valgrind (or both) I can't
yet say.

Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------