[Ur] Rough edges.

[Michael Stone]

On 3/9/10, Michael Stone <michael.r.stone at gmail.com> wrote:
> On 3/9/10, Adam Chlipala <adamc at impredicative.com> wrote:
>> Michael Stone wrote:
>>> uw_malloc
>>> :   uw_malloc is doing something that I don't understand, in that the
>>> following approximate snippet:
>>>
>>>      size_t len = ...
>>>      char* c = uw_malloc(ctx, len);
>>>      if (!c) uw_error(ctx, FATAL, "couldn't allocate %d bytes", len);
>>>      memset(c, 0, len);
>>>
>>> sometimes segfaults on the memset. (I was able to work around this
>>> problem by using a fixed-size stack-allocated array.)
>>>
>>
>> That is definitely not supposed to happen.  Would you mind reducing this
>> to a minimal example that still exhibits the problem and then submitting
>> the source code in a Mantis bug report?

Adam,

I haven't found a minimal always-reproducible example yet but I do
have several observations for you, which result from testing on

$ uname -a
Linux mstone 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 22:07:16 UTC
2009 x86_64 GNU/Linux

The observations are:

  1. The error is not deterministically reproducible and appears to be
a heisenbug. (It is consistently non-reproducible under valgrind.)

  2. When segfaults occur, the returned address is unmapped. (Other
subsequent addresses may also be unmapped; I haven't checked.)

  3. The addresses which are unmapped are sometimes quite large; e.g.,
0xffffffff9387408a, and sometimes quite small, e.g., 0x6b14308a. (Note
that -1 - 0xffffffff9387408a = 0x6c78bf75, which is quite comparable
to 0x6b14308a.)

  4. src/c/urweb.c does not check the return codes of calls to
malloc() and realloc() for NULL.

I'll write again if/when I come up with a new insight or datum.

Regards,

Michael