All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Bug#285281: core dump on amd64 (gcc-3.4)
Date: Thu, 16 Dec 2004 04:55:07 +0000	[thread overview]
Message-ID: <20041216045312.GA8896@in.ibm.com> (raw)
In-Reply-To: <20041215085045.GA4444@wonderland.linux.it>

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

  parent reply	other threads:[~2004-12-16  4:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-15  8:50 Bug#285281: core dump on amd64 (gcc-3.4) Marco d'Itri
2004-12-15 12:25 ` Marco d'Itri
2004-12-15 13:27 ` Kay Sievers
2004-12-15 16:40 ` Daniel Stekloff
2004-12-16  4:55 ` Ananth N Mavinakayanahalli [this message]
2004-12-16  7:20 ` Kay Sievers
2004-12-17 19:07 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041216045312.GA8896@in.ibm.com \
    --to=ananth@in.ibm.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.