Bug#285281: core dump on amd64 (gcc-3.4)

Bug#285281: core dump on amd64 (gcc-3.4)

[Marco d'Itri]

clsdev->directory is NULL, is this a bug in libsysfs or udev?
Apparently this only happens on amd64.

----- Forwarded message from martin-deb@zero-based.org -----

Subject: Bug#285281: core dump on amd64 (gcc-3.4)
Reply-To: martin-deb@zero-based.org, 285281@bugs.debian.org
From: martin-deb@zero-based.org
To: 285281@bugs.debian.org
Cc: Harald Dunkel <harald.dunkel@t-online.de>

On Sun, Dec 12, 2004 at 11:27:48AM +0100, Marco d'Itri wrote:
> On Dec 12, Harald Dunkel <harald.dunkel@t-online.de> wrote:
> 
> > There seems to be something wrong with udev at least on
> > amd64 (gcc-3.4).
>
> Please do your best to get a stack trace, possibly from the unstripped
> binary.

I see the same behavior on amd64 with gcc-3.3. Here is a stacktrace:


GNU gdb 6.3-debian
[...]

Core was generated by `udev vc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
#0  0x0000000000403024 in sysfs_get_classdev_attr (clsdev=0x518260, name=0x40dcac "dev") at libsysfs/sysfs_class.c:643
643             if (clsdev->directory->subdirs = NULL) 
(gdb) backtrace
#0  0x0000000000403024 in sysfs_get_classdev_attr (clsdev=0x518260, name=0x40dcac "dev") at libsysfs/sysfs_class.c:643
#1  0x000000000040904e in get_major_minor (class_dev=0x0, udev=0x7fbffff330) at udev_add.c:57
#2  0x0000000000409874 in udev_add_device (udev=0x7fbffff330, class_dev=0x518260) at udev_add.c:287
#3  0x0000000000402009 in main (argc=2, argv=0x7fbffffdb8, envp=0x0) at udev.c:197
(gdb) print *clsdev
$1 = {name = "vcs1", '\0' <repeats 45 times>, classname = "vc", '\0' <repeats 47 times>, 
  path = "/sys/class/vc/vcs1", '\0' <repeats 236 times>, parent = 0x0, sysdevice = 0x0, driver = 0x0, directory = 0x0}


Martin

----- End forwarded message -----

-- 
ciao, |
Marco | [9803 vebcDBN29Lxms]


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bug#285281: core dump on amd64 (gcc-3.4)

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

On Dec 15, Marco d'Itri <md@Linux.IT> wrote:

> clsdev->directory is NULL, is this a bug in libsysfs or udev?

From further discussions on the debian-amd64 mailing list I understand
that the bug was introduced in 047 or 048.

-- 
ciao, |
Marco | [9811 stQz.IcAJS5Nc]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Bug#285281: core dump on amd64 (gcc-3.4)

[Kay Sievers]

On Wed, 2004-12-15 at 09:50 +0100, Marco d'Itri wrote:
> clsdev->directory is NULL, is this a bug in libsysfs or udev?
> Apparently this only happens on amd64.
> 
> ----- Forwarded message from martin-deb@zero-based.org -----

> #0  0x0000000000403024 in sysfs_get_classdev_attr (clsdev=0x518260, name=0x40dcac "dev") at libsysfs/sysfs_class.c:643
> 643             if (clsdev->directory->subdirs = NULL) 
> (gdb) backtrace

It is caused by the vc class behavior, to emit events on every open()
and close(). We get a lot of events on bootup for every vc device, cause
it is several times reopened. This causes the sysfs-dir to go away while
the device is opened in libsysfs. This simple test program:

#include <stdio.h>
#include <unistd.h>
#include <stddef.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <errno.h>

#include "libsysfs/sysfs/libsysfs.h"


int main(int argc, char *argv[], char *envp[])
{
        struct sysfs_class_device *class_dev;
        struct sysfs_attribute *attr;

        mkdir("test-sys", 0775);
        mkdir("test-sys/class", 0775);
        mkdir("test-sys/class/test", 0775);

        setenv("SYSFS_PATH", "test-sys", 1);

        printf("open\n");
        class_dev = sysfs_open_class_device_path("test-sys/class/test");
        printf("%p\n", class_dev);

        printf("rmdir\n");
        rmdir("test-sys/class/test");

        printf("read attr\n");
        attr = sysfs_get_classdev_attr(class_dev, "dev");
}

segfaults every time:
  [kay@pim udev.kay]$ gcc -g -I libsysfs/sysfs -I libsysfs -o bug bug.c libsysfs/sysfs.a
  [kay@pim udev.kay]$ ./bug 
  open
  0x804f0d8
  rmdir
  read attr
  Segmentation fault


This seems to fix it:

=== libsysfs/sysfs_class.c 1.11 vs edited ==--- 1.11/libsysfs/sysfs_class.c 2004-10-20 05:15:26 +02:00
+++ edited/libsysfs/sysfs_class.c       2004-12-15 14:20:13 +01:00
@@ -640,6 +640,9 @@
                        return cur;
        }
 
+       if (clsdev->directory = NULL)
+               return NULL;
+
        if (clsdev->directory->subdirs = NULL) 
                if ((sysfs_read_dir_subdirs(clsdev->directory)) != 0 ||
                    clsdev->directory->subdirs = NULL) 


Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bug#285281: core dump on amd64 (gcc-3.4)

[Daniel Stekloff]

On Wed, 2004-12-15 at 05:27, Kay Sievers wrote:
> On Wed, 2004-12-15 at 09:50 +0100, Marco d'Itri wrote:
> > clsdev->directory is NULL, is this a bug in libsysfs or udev?
> > Apparently this only happens on amd64.



This is definitely a libsysfs bug.



> > ----- Forwarded message from martin-deb@zero-based.org -----
> 
> > #0  0x0000000000403024 in sysfs_get_classdev_attr (clsdev=0x518260, name=0x40dcac "dev") at libsysfs/sysfs_class.c:643
> > 643             if (clsdev->directory->subdirs = NULL) 
> > (gdb) backtrace
> 
> It is caused by the vc class behavior, to emit events on every open()
> and close(). We get a lot of events on bootup for every vc device, cause
> it is several times reopened. This causes the sysfs-dir to go away while
> the device is opened in libsysfs. This simple test program:
> 
> #include <stdio.h>
> #include <unistd.h>
> #include <stddef.h>
> #include <stdlib.h>
> #include <string.h>
> #include <ctype.h>
> #include <errno.h>
> 
> #include "libsysfs/sysfs/libsysfs.h"
> 
> 
> int main(int argc, char *argv[], char *envp[])
> {
>         struct sysfs_class_device *class_dev;
>         struct sysfs_attribute *attr;
> 
>         mkdir("test-sys", 0775);
>         mkdir("test-sys/class", 0775);
>         mkdir("test-sys/class/test", 0775);
> 
>         setenv("SYSFS_PATH", "test-sys", 1);
> 
>         printf("open\n");
>         class_dev = sysfs_open_class_device_path("test-sys/class/test");
>         printf("%p\n", class_dev);
> 
>         printf("rmdir\n");
>         rmdir("test-sys/class/test");
> 
>         printf("read attr\n");
>         attr = sysfs_get_classdev_attr(class_dev, "dev");
> }
> 
> segfaults every time:
>   [kay@pim udev.kay]$ gcc -g -I libsysfs/sysfs -I libsysfs -o bug bug.c libsysfs/sysfs.a
>   [kay@pim udev.kay]$ ./bug 
>   open
>   0x804f0d8
>   rmdir
>   read attr
>   Segmentation fault
> 
> 
> This seems to fix it:
> 
> === libsysfs/sysfs_class.c 1.11 vs edited ==> --- 1.11/libsysfs/sysfs_class.c 2004-10-20 05:15:26 +02:00
> +++ edited/libsysfs/sysfs_class.c       2004-12-15 14:20:13 +01:00
> @@ -640,6 +640,9 @@
>                         return cur;
>         }
>  
> +       if (clsdev->directory = NULL)
> +               return NULL;
> +
>         if (clsdev->directory->subdirs = NULL) 
>                 if ((sysfs_read_dir_subdirs(clsdev->directory)) != 0 ||
>                     clsdev->directory->subdirs = NULL) 



We wrongly assume that the directory is there or is opened when
sysfs_get_classdev_attributes() runs prior to this. 

We'll apply this patch to the tree.

Thanks,

Dan


> 
> Thanks,
> Kay
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bug#285281: core dump on amd64 (gcc-3.4)

[Ananth N Mavinakayanahalli]

On Wed, Dec 15, 2004 at 02:27:13PM +0100, Kay Sievers wrote:
> On Wed, 2004-12-15 at 09:50 +0100, Marco d'Itri wrote:
> > clsdev->directory is NULL, is this a bug in libsysfs or udev?
> > Apparently this only happens on amd64.
> > 
> > ----- Forwarded message from martin-deb@zero-based.org -----
> 
> > #0  0x0000000000403024 in sysfs_get_classdev_attr (clsdev=0x518260, name=0x40dcac "dev") at libsysfs/sysfs_class.c:643
> > 643             if (clsdev->directory->subdirs = NULL) 
> > (gdb) backtrace
> 
> It is caused by the vc class behavior, to emit events on every open()
> and close(). We get a lot of events on bootup for every vc device, cause
> it is several times reopened. This causes the sysfs-dir to go away while
> the device is opened in libsysfs. This simple test program:
> 
> This seems to fix it:
> 
> === libsysfs/sysfs_class.c 1.11 vs edited ==> --- 1.11/libsysfs/sysfs_class.c 2004-10-20 05:15:26 +02:00
> +++ edited/libsysfs/sysfs_class.c       2004-12-15 14:20:13 +01:00
> @@ -640,6 +640,9 @@
>                         return cur;
>         }
>  
> +       if (clsdev->directory = NULL)
> +               return NULL;
> +
>         if (clsdev->directory->subdirs = NULL) 
>                 if ((sysfs_read_dir_subdirs(clsdev->directory)) != 0 ||
>                     clsdev->directory->subdirs = NULL) 
> 

Thanks for the patch Kay. I have applied this to my tree too.

Thanks,
Ananth


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bug#285281: core dump on amd64 (gcc-3.4)

[Kay Sievers]

On Thu, 2004-12-16 at 10:23 +0530, Ananth N Mavinakayanahalli wrote:
> On Wed, Dec 15, 2004 at 02:27:13PM +0100, Kay Sievers wrote:
> > On Wed, 2004-12-15 at 09:50 +0100, Marco d'Itri wrote:
> > > clsdev->directory is NULL, is this a bug in libsysfs or udev?
> > > Apparently this only happens on amd64.
> > > 
> > > ----- Forwarded message from martin-deb@zero-based.org -----
> > 
> > > #0  0x0000000000403024 in sysfs_get_classdev_attr (clsdev=0x518260, name=0x40dcac "dev") at libsysfs/sysfs_class.c:643
> > > 643             if (clsdev->directory->subdirs = NULL) 
> > > (gdb) backtrace
> > 
> > It is caused by the vc class behavior, to emit events on every open()
> > and close(). We get a lot of events on bootup for every vc device, cause
> > it is several times reopened. This causes the sysfs-dir to go away while
> > the device is opened in libsysfs. This simple test program:
> > 
> > This seems to fix it:
> > 
> > === libsysfs/sysfs_class.c 1.11 vs edited ==> > --- 1.11/libsysfs/sysfs_class.c 2004-10-20 05:15:26 +02:00
> > +++ edited/libsysfs/sysfs_class.c       2004-12-15 14:20:13 +01:00
> > @@ -640,6 +640,9 @@
> >                         return cur;
> >         }
> >  
> > +       if (clsdev->directory = NULL)
> > +               return NULL;
> > +
> >         if (clsdev->directory->subdirs = NULL) 
> >                 if ((sysfs_read_dir_subdirs(clsdev->directory)) != 0 ||
> >                     clsdev->directory->subdirs = NULL) 
> > 
> 
> Thanks for the patch Kay. I have applied this to my tree too.

Nice, thanks. Greg, please pull it from:
  bk://vrfy.bkbits.net/udev

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Bug#285281: core dump on amd64 (gcc-3.4)

[Greg KH]

On Thu, Dec 16, 2004 at 08:20:16AM +0100, Kay Sievers wrote:
> > Thanks for the patch Kay. I have applied this to my tree too.
> 
> Nice, thanks. Greg, please pull it from:
>   bk://vrfy.bkbits.net/udev

Pulled from, thanks for applying this, and the other patches.

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel