On 3/9/10, Michael Stone <[email protected]> wrote: > On 3/9/10, Adam Chlipala <[email protected]> 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 _______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
