SYSTEM WARNING: Creating default object from empty value

Mantis - Squeak
Viewing Issue Advanced Details
7358 VM crash have not tried 06-27-09 18:41 03-11-11 13:33
0007358: UUID>>initialize may crash VM for some images
Pharo users report VM crashes on UUID>>initialize when the UUID plugin is present in the VM. This is apparently specific to Pharo usage, but is presumably a bug in the UUID plugin. See [^] for background.
has duplicate 0007371closed lewis uuid plugin issue, maybe: trying to select bigDisplay in the preferences browser generates a segfault 
has duplicate 0007614closed lewis Fresh 4.2 crashes on Debian x64 on change interface global settings from menues 

07-17-09 16:56   
See duplicate issue 7371 for a better problem description with gdb output.
07-19-09 01:27   
Nicolas Cellier (on vm-dev) asks:
> Anything to do with [^] ?

Above bug report sounds similar to symptoms reported here. There is a C test program to confirm, so if someone who is experiencing the UUID bug on Squeak could run that program and report back here, it would be very helpful.
07-19-09 01:33   
Bryce Kampjes notes (on vm-dev):

> I think another work around was to increase the size of the Squeak UUID
> object by a byte which suggests the bug is an off by one error.

If true, this suggests either an off-by-one problem or a byte alignment problem. I don't see any off-by-one issues in the code, so perhaps a platform- or compiler-specific alignment issue?
07-20-09 10:07   
On my 64bit Ubuntu 9.04 system, the C code in the bugzilla report works properly, no matter how I compile it (staticly, with or without -g, with or without -O2).

I'll try it on my 32bit Ubuntu 9.04 system when I get home. The uuid-dev package on my 64bit system is from e2fsprogs-1.41.4.

I'm not certain, but I think the problem has to do with threading defines in libuuid's gen_uuid.c file.

This is an excerpt of gen_uuid.c in e2fsprogs-1.41.4, of get_random_fd() (and related defines): [^] (see line 34).

This is gen_uuid.c in e2fsprogs-1.40: [^]

I tried replacing the uuid_generate() call in the UUIDPlugin to uuid_generate_time(). That avoids the calls to get_random_fd(), but crashes while trying to read from a variable defined as THREAD_LOCAL.

Oh, and I found this over the weekend: [^]
That's the exact same symptom I see.

07-21-09 03:50   
Tried the bugzilla code and confirmed -- it doesn't crash on my 32bit Ubuntu 9.04 system.
07-21-09 16:14   
I tried the test in the Redhat report on Debian Unstable on x86-32. I had to add an include declaration but once I compiled and ran it it ran fine.

However if this is a build problem then the test needs to be done by the person who built the VM where the problem is being reported. I noticed it with a VM built I assume by Bryce. If I understand this issue correctly, then my doing this test compile proves nothing. Sound right?
07-21-09 19:05   
Yes, the problem doesn't show up until the first time you call uuid_generate().

I wrote some code to dlopen() UUIDPlugin, and it works, too: [^]

I downloaded e2fsprogs-1.41.8 (the latest release at, [^] and if I build it with ./configure --disable-tls, the resulting works flawlessly.

I have no idea what the problem is, and why squeak fails but my test app works.
04-13-10 11:49   
See vm-dev list. Symptoms of the libuuid bug apparently do not appear if the plugin is built as internal.

On Tue, Apr 13, 2010 at 08:12:26AM +0200, laurent laffont wrote:
> On Tue, Apr 13, 2010 at 1:36 AM, David T. Lewis <> wrote:
> >
> > Can you confirm that the bug does *not* exist when you build the plugin
> > as internal, and that it *does" exist if you build it external on the
> > same platform. It would be a big help to know if this is the case.
> >
> > My impression up until now is that this is a bug in the runtime libuuid
> > library, and that it has something to do with running a program with
> > pthreads (i.e. it does not happen with a simple test program). But I
> > have never actually seen the bug on my own system, so I'm guessing based
> > on some google searches and the information that I read on the Pharo list.
> I have just built last release (Squeak- with UUID as
> internal and it works like a charm. All Pharo 1.0-RC4 tests green ! Thank
> you all.
> So there's a real problem when UUID is external.
> Cheers,
> Laurent Laffont
05-19-10 13:48   
To summarize: The bug exists in some versions of libuuid on some Linux distributions. The workaround is to compile the plugin internal. The latest versions of Unix VM have the plugin compiled internally, although some users may still experience problems if they have a leftover external plugin from a prior installation.

If you experience this problem, then get the latest Unix VM and delete any existing copies of the external plugin.
05-19-10 13:50   
Resolved in latest Unix VMs. The UUID plugin must be compiled internally to avoid a bug in some versions of libuuid.
10-08-10 15:06   
Changing status from resolved back to acknowledged. Levente Uzonyi reports that the plugin, if built internally, will crash the VM if the target system does not have libuuid installed. [^]

I reproduced this by removing the libuuid libraries from my Linux system. The result is that the VM fails to load due to the missing library. It never reaches main(), so this is not something that can be addressed in the code. Presumably a static linked VM would work, but this would probably lead to problems elsewhere.

Summary: Building UUIDPlugin internally is a workaround for the libuuid bug that is present on some systems, but it results in an unusable VM for people who do not have the uuid library installed with their OS.
10-08-10 16:26   
AFAIK 64-bit versions of Ubuntu 8.04, 8.10 and Debian 5.0 don't have a
32-bit package for libuuid. A relevant bug report can be found here: [^]

01-20-11 13:37   
From: Aleksej Saushev <>
Date: Thu, 20 Jan 2011 04:22:25 +0300
Subject: [Vm-dev] [patch] Use uuidgen(2) API on NetBSD


NetBSD has its own UUID API, which is slightly different, see patch below.

There's also no libuuid, all functions are in libc, but I'm not sure
how to fix it with cmake right away. I'm removing "-luuid" flag with
compiler wrapper (we have this kind of functionality in pkgsrc).

Use uuidgen(2) on NetBSD.

--- unix/plugins/UUIDPlugin/sqUnixUUID.c.orig 2009-08-26 22:12:10.000000000 +0400
+++ unix/plugins/UUIDPlugin/sqUnixUUID.c 2011-01-18 01:02:30.000000000 +0300
@@ -1,4 +1,8 @@
 #include "config.h"
+#if defined(__NetBSD__)
+#include <sys/types.h>
+#include <sys/uuid.h>
 #include <uuid.h>
 #include "sq.h"

@@ -15,7 +19,11 @@
 int MakeUUID(char *location)
   uuid_t uuid;
+#if defined(__NetBSD__)
+ uuidgen(&uuid, 1);
   memcpy((void *)location, (void *)&uuid, sizeof(uuid));
   return 1;
02-16-11 00:38   
I rewrote the sqUUIDInit function to test if the plugin (MakeUUID) would crash with segfault when it's used. sqUUIDInit returns 0 instead of 1 if the plugin would crash, or the test can't be performed. This means that the plugin won't be loaded in these cases. I'm not sure if the VM will try to load it at every primitive invocation in this case, but I didn't see any performance drop when the plugin couldn't be loaded compared to removing the primitive call from UUID >> #primMakeUUID in the image.

Since I can't reproduce the problem (an OS-VM combination would have been nice where the plugin reliably crashed), I tested the new code with "artifical segfaults"(foo[1000000000] = 1) and it works fine for me.

I doubt we will be able to solve this problem any better, since the cause of the problem is not in the plugin or the VM.

I'm not a C or VM guru, so feel free to modify the code which is available from here [^] . All changes are available under the MIT license. I also built the plugin with this fix using the source code of the Unix VM which is available here: [^] .
03-11-11 13:33   
In addition to bug 7614, confirmation:
After I removed UUID plugin from its directory:
    $ mv Contents/Linux-i686/lib/squeak/4.4.7-2357/so.UUIDPlugin .
all actions that caused crashes before, now do work fine...
(Well, not very fine - some of results look ugly %) but at least it works.)
When I return the plugin to its original place crashes return too.