It's not clear from the reports whether this is known to be the first
uuid_generate call.
It might help if someone afflicted could say
if this is always the first call...
Since it does look dead simple on the face of it.
But there's that almost-ambiguous extra indirection in there
int MakeUUID(char *location)
{
uuid_t uuid;
uuid_generate(uuid);
memcpy((void *)location, (void *)&uuid, sizeof(uuid));
return 1;
}
since uuid_t is an array type, the & in (void *) & uuid
is one of those C miseries; who knows?
Anyway, is it the first uuid, or a subsequent one, that dies?
-b
>
> On Sat, Jul 18, 2009 at 08:33:32AM +0200, Brent Pinkney wrote:
>>
>>> As a workaround, how is this?
>>>
>>> UUID>>initialize
>>> "Some unix versions crash with the UUID prim, so disable it for
>>> all of 'em"
>>> Smalltalk platformName = 'unix'
>>> ifTrue:[UUIDGenerator default generateBytes: self forVersion: 4]
>>> ifFalse:[self primMakeUUID].
>>
>> No lads, we use this in a production telco environment - lets fix
>> it properly.
>
> Agreed.
>
> Someone (faried) has added an additional Mantis report on this
> problem, see
>
http://bugs.squeak.org/view.php?id=7371.
>
> The new bug report contains some useful gdb output showing a
> segfault occuring
> in the actual uuid_generate() library call. The VM support code
> wrapping this
> call looks dead simple, so I'm hard pressed to see how that could be
> wrong.
> This plugin is trivial; we must be missing something obvious.
>
> Note, I'm not actually working on this bug, and I've never seen it
> happen. I'm
> just tracking it in Mantis and hoping that someone can point to a
> solution.
>
> Dave
>
Locked
