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