Mantis Bugtracker
  

Viewing Issue Advanced Details Jump to Notes ] View Simple ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0007358 [Squeak] VM crash have not tried 06-27-09 18:41 03-11-11 13:33
Reporter lewis View Status public  
Assigned To lewis
Priority normal Resolution fixed Platform
Status acknowledged   OS
Projection none   OS Version
ETA none Fixed in Version Product Version
  Product Build
Summary 0007358: UUID>>initialize may crash VM for some images
Description 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 http://code.google.com/p/pharo/issues/detail?id=723 [^] for background.
Steps To Reproduce
Additional Information
Attached Files

- Relationships

SYSTEM WARNING: Creating default object from empty value

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 

- Notes
(0013200 - 74 - 74 - 74 - 74 - 74 - 74)
lewis
07-17-09 16:56

See duplicate issue 7371 for a better problem description with gdb output.
 
(0013201 - 343 - 382 - 532 - 532 - 532 - 532)
lewis
07-19-09 01:27

Nicolas Cellier (on vm-dev) asks:
>
> Anything to do with https://bugzilla.redhat.com/show_bug.cgi?id=471801 [^] ?
>

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.
 
(0013202 - 368 - 404 - 404 - 404 - 404 - 404)
lewis
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?
 
(0013208 - 919 - 1009 - 1309 - 1309 - 1309 - 1309)
faried
07-20-09 10:07
edited on: 07-20-09 10:10

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): http://pastie.org/551905 [^] (see line 34).

This is gen_uuid.c in e2fsprogs-1.40: http://bit.ly/BieO5 [^]

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: http://bugs.python.org/issue6059 [^]
That's the exact same symptom I see.

 
(0013209 - 89 - 89 - 89 - 89 - 89 - 89)
faried
07-21-09 03:50

Tried the bugzilla code and confirmed -- it doesn't crash on my 32bit Ubuntu 9.04 system.
 
(0013210 - 435 - 447 - 447 - 447 - 447 - 447)
KenCausey
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?
 
(0013211 - 427 - 463 - 663 - 663 - 663 - 663)
faried
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: http://pastie.org/553759 [^]

I downloaded e2fsprogs-1.41.8 (the latest release at http://e2fsprogs.sf.net/), [^] and if I build it with ./configure --disable-tls, the resulting libuuid.so works flawlessly.

I have no idea what the problem is, and why squeak fails but my test app works.
 
(0013692 - 1134 - 1385 - 1426 - 1426 - 1426 - 1426)
lewis
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 <lewis@mail.msen.com> 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-4.0.3.2200-src.tar.gz) 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
 
(0013783 - 438 - 450 - 450 - 450 - 450 - 450)
lewis
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.
 
(0013784 - 116 - 116 - 116 - 116 - 116 - 116)
lewis
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.
 
(0013881 - 803 - 839 - 1043 - 1043 - 1043 - 1043)
lewis
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.

http://lists.gforge.inria.fr/pipermail/pharo-project/2010-October/033760.html [^]

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.
 
(0013882 - 210 - 240 - 400 - 400 - 400 - 400)
lewis
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:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540014 [^]


Levente
 
(0014025 - 1075 - 1465 - 1556 - 1556 - 1556 - 1556)
lewis
01-20-11 13:37

From: Aleksej Saushev <asau@inbox.ru>
To: vm-dev@lists.squeakfoundation.org
Date: Thu, 20 Jan 2011 04:22:25 +0300
Subject: [Vm-dev] [patch] Use uuidgen(2) API on NetBSD

  Hello!

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>
+#endif
 #include <uuid.h>
 #include "sq.h"

@@ -15,7 +19,11 @@
 int MakeUUID(char *location)
 {
   uuid_t uuid;
+#if defined(__NetBSD__)
+ uuidgen(&uuid, 1);
+#else
   uuid_generate(uuid);
+#endif
   memcpy((void *)location, (void *)&uuid, sizeof(uuid));
   return 1;
 }
 
(0014053 - 1182 - 1234 - 1512 - 1512 - 1512 - 1512)
leves
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 http://leves.web.elte.hu/squeak/sqUnixUUID.c [^] . All changes are available under the MIT license. I also built the plugin with this fix using the source code of the 4.4.7.2357 Unix VM which is available here: http://leves.web.elte.hu/squeak/so.UUIDPlugin [^] .
 
(0014070 - 362 - 412 - 412 - 412 - 412 - 412)
sergio
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.
 

- Issue History
Date Modified Username Field Change
06-27-09 18:41 lewis New Issue
06-27-09 18:41 lewis Status new => assigned
06-27-09 18:41 lewis Assigned To  => lewis
06-27-09 18:41 lewis Issue Monitored: lewis
07-17-09 16:54 lewis Relationship added has duplicate 0007371
07-17-09 16:56 lewis Note Added: 0013200
07-19-09 01:27 lewis Note Added: 0013201
07-19-09 01:33 lewis Note Added: 0013202
07-20-09 10:07 faried Note Added: 0013208
07-20-09 10:10 faried Note Edited: 0013208
07-20-09 10:10 faried Note Edited: 0013208
07-21-09 03:50 faried Note Added: 0013209
07-21-09 16:14 KenCausey Note Added: 0013210
07-21-09 19:05 faried Note Added: 0013211
03-29-10 17:31 laza Relationship added child of 0007480
04-07-10 02:56 laza Relationship deleted child of 0007480
04-13-10 11:49 lewis Note Added: 0013692
04-13-10 12:39 laza Status assigned => testing
05-19-10 13:48 lewis Note Added: 0013783
05-19-10 13:50 lewis Status testing => resolved
05-19-10 13:50 lewis Resolution open => fixed
05-19-10 13:50 lewis Note Added: 0013784
10-08-10 15:06 lewis Note Added: 0013881
10-08-10 15:06 lewis Status resolved => acknowledged
10-08-10 16:26 lewis Note Added: 0013882
01-20-11 13:37 lewis Note Added: 0014025
02-16-11 00:38 leves Note Added: 0014053
03-10-11 17:25 KenCausey Relationship added has duplicate 0007614
03-11-11 13:33 sergio Note Added: 0014070


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
125 total queries executed.
72 unique queries executed.
Powered by Mantis Bugtracker