After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 573929 - nautilus crashed with SIGSEGV in start_thread()
nautilus crashed with SIGSEGV in start_thread()
Status: RESOLVED FIXED
Product: brasero
Classification: Applications
Component: libbrasero-media
2.25.x
Other Linux
: Normal critical
: 2.26
Assigned To: Brasero maintainer(s)
Brasero maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-03-03 15:13 UTC by Pedro Villavicencio
Modified: 2009-04-07 14:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Said patch (1.21 KB, patch)
2009-04-01 18:35 UTC, Philippe Rouquier
committed Details | Review
Another patch (to be added on top of the previous) (1.90 KB, patch)
2009-04-06 13:53 UTC, Philippe Rouquier
committed Details | Review
brasero -g --brasero-media-debug (1.35 KB, application/octet-stream)
2009-04-06 19:46 UTC, aginies
  Details
brasero -g --brasero-media-debug (597.70 KB, application/x-bzip)
2009-04-07 10:26 UTC, aginies
  Details
brasero --brasero-media-debug > log (3.12 KB, text/plain)
2009-04-07 12:26 UTC, aginies
  Details

Description Pedro Villavicencio 2009-03-03 15:13:47 UTC
this report has been filed here:

https://bugs.edge.launchpad.net/ubuntu/+source/brasero/+bug/335942

".

Thread 3 (process 6831)

  • #0 mprotect
    from /lib/ld-linux.so.2
  • #1 _dl_protect_relro
    from /lib/ld-linux.so.2
  • #2 _dl_relocate_object
    from /lib/ld-linux.so.2
  • #3 dl_open_worker
    from /lib/ld-linux.so.2
  • #4 _dl_catch_error
    from /lib/ld-linux.so.2
  • #5 _dl_open
    from /lib/ld-linux.so.2
  • #6 dlopen_doit
    from /lib/tls/i686/cmov/libdl.so.2
  • #7 _dl_catch_error
    from /lib/ld-linux.so.2
  • #8 _dlerror_run
    from /lib/tls/i686/cmov/libdl.so.2
  • #9 dlopen
    from /lib/tls/i686/cmov/libdl.so.2
  • #10 g_module_open
    at /build/buildd/glib2.0-2.19.8/gmodule/gmodule-dl.c line 99
  • #11 nautilus_module_load
    at nautilus-module.c line 73
  • #12 IA__g_type_module_use
    at /build/buildd/glib2.0-2.19.8/gobject/gtypemodule.c line 257
  • #13 nautilus_module_setup
    at nautilus-module.c line 173
  • #14 nautilus_application_startup
    at nautilus-application.c line 466
  • #15 main
    at nautilus-main.c line 492

Thread 1 (process 6833)

  • #0 brasero_medium_get_page_2A_write_speed_desc
    at brasero-medium.c line 1414
  • #1 brasero_medium_init_real
    at brasero-medium.c line 1441
  • #2 brasero_medium_probe_thread
    at brasero-medium.c line 2922
  • #3 g_thread_create_proxy
    at /build/buildd/glib2.0-2.19.8/glib/gthread.c line 635
  • #4 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #5 clone
    from /lib/tls/i686/cmov/libc.so.6"

Comment 1 Luis Medinas 2009-03-04 08:47:09 UTC
Doesn't seem a segfault on brasero, can anyone also reproduce this ?
I can't with nautilus 2.25.90 and brasero trunk.
Comment 2 Yann 2009-03-12 16:32:38 UTC
Does this bug has to do with this other bug report:
https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/339993

In this last bug report, I attached an ugly patch that could help to find the bug.
Comment 3 Ian! D. Allen 2009-03-30 08:06:19 UTC
This is still a problem in 9.04 Jaunty Beta.

This Nautilus repeated crashing makes it difficult to configure Ubuntu 9.04
to run well in a VMware virtual machine, since the VMware Tools CDROM ISO
image can't be attached without causing a Nautilus crash loop that fills
the task bar. You have to SIGSTOP Nautilus, mount the CDROM ISO file
manually, install VMware tools, unmount the ISO, then SIGCONT Nautilus.

See https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/344371
Comment 4 Pedro Villavicencio 2009-03-31 15:24:02 UTC
Is there any other information needed on this report? we are still having duplicates on the downstream report.
Comment 5 Luis Medinas 2009-03-31 17:18:37 UTC
Pedro isn't this a duplicate of bug #576439 ?
Comment 6 Pedro Villavicencio 2009-04-01 14:18:17 UTC
Luis not sure, the fix for bug 576439 was already applied on the brasero Ubuntu package (2.26.0-0ubuntu2) 
Comment 7 Philippe Rouquier 2009-04-01 18:34:39 UTC
Thanks for the report and help. I added a fix for the bug. Please test it; it's both in trunk and stable.
Comment 8 Philippe Rouquier 2009-04-01 18:35:39 UTC
Created attachment 131859 [details] [review]
Said patch

Here is the patch to test and that was added to both trunk and stable.
Comment 9 aginies 2009-04-06 09:30:40 UTC
i have got a crash using brasero too.
released of brasero used:
libbrasero-devel-2.26.0-2mdv2009.1
libbrasero0-2.26.0-2mdv2009.1
brasero-2.26.0-2mdv2009.1
brasero-debug-2.26.0-2mdv2009.1

- put a CD in the cdrom drive (tested with 3 CD)
- start brasero
- brasero seg fault


-----------------
(gdb) run brasero
Starting program: /usr/bin/brasero brasero
[Thread debugging using libthread_db enabled]
[New Thread 0xb69736e0 (LWP 20875)]
Detaching after fork from child process 20878.
Detaching after fork from child process 20879.
[New Thread 0xb67a3b90 (LWP 20880)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb67a3b90 (LWP 20880)]
brasero_medium_init_real (object=0x84e38d0, handle=0x85d1ab8) at brasero-medium.c:1315
1315                    priv->rd_speeds [i] = BRASERO_GET_32 (desc->rd_speed);
(gdb) thread apply all bt

Thread 2 (Thread 0xb67a3b90 (LWP 20880))

  • #0 brasero_medium_init_real
    at brasero-medium.c line 1315
  • #1 brasero_medium_probe_thread
    at brasero-medium.c line 2996
  • #2 g_thread_create_proxy
    at gthread.c line 635
  • #3 start_thread
    from /lib/i686/libpthread.so.0
  • #4 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 130

Thread 1 (Thread 0xb69736e0 (LWP 20875))

  • #0 _dl_map_object_from_fd
    at dynamic-link.h line 114
  • #1 _dl_map_object
    at dl-load.c line 2239
  • #2 dl_open_worker
    at dl-open.c line 293
  • #3 _dl_catch_error
    at dl-error.c line 178
  • #4 _dl_open
    at dl-open.c line 596
  • #5 dlopen_doit
    at dlopen.c line 67
  • #6 _dl_catch_error
    at dl-error.c line 178
  • #7 _dlerror_run
    at dlerror.c line 164
  • #8 __dlopen
    at dlopen.c line 88
  • #9 g_module_open
    at gmodule-dl.c line 99
  • #10 ??
  • #11 ??
  • #12 ??



If i remove the CD from my CDrom drive, brasero is able to start.
CD writer/DVD LG (HL-DT-ST RW/DVD GCC-4521B)
Comment 10 Frederic Crozat 2009-04-06 09:32:36 UTC
regarding the previous comment, test package from Mandriva contains all fixes from 2.26 branch (including patch in this bug).
Comment 11 Philippe Rouquier 2009-04-06 13:50:53 UTC
Thanks for this new stack trace.
I think they are both unrelated (except they both get the speed). The two crashes happen in different functions.
The patch attached seems to fix the issues the ubuntu people reported which seems to indicate I'm right about that.

Now given the line where it happens I suspect i is too big or desc pointer has gone too far.
priv->rd_speeds [i] = BRASERO_GET_32 (desc->rd_speed)

That's why I need to know a few more things please:
could you tell me what's the value of i, desc, size, num_desc and wrt_perf (all local variables).

@aginies@gmail.com: Just in case, once you ran gdb and brasero crashed, type the following:
print i
print desc
...

Just one last question, does this bug happen with all kinds of discs? If not, what are the relevant type(s) of discs?
(Of course I also assume your drive is a writer right?)

Thanks in advance
Comment 12 Philippe Rouquier 2009-04-06 13:53:18 UTC
Created attachment 132190 [details] [review]
Another patch (to be added on top of the previous)

This patch may help to fix the crash if my assumptions are correct. Please test.
Comment 13 Philippe Rouquier 2009-04-06 13:59:32 UTC
NOTE: the above patch was added to both trunk/stable already as it won't hurt even if it does do any good.
Comment 14 aginies 2009-04-06 14:24:27 UTC
> @aginies@gmail.com: Just in case, once you ran gdb and brasero crashed, type
> the following:
> print i
> print desc
> ...


no more info:
-----------
(gdb) print i
No symbol "i" in current context.
(gdb) print desc
No symbol "desc" in current context.
-----------

> Just one last question, does this bug happen with all kinds of discs? If not,
> what are the relevant type(s) of discs?
> (Of course I also assume your drive is a writer right?)

yes all kind, i test with a starcraft CDrom, a CD with images, a Mandriva CD. Same result (brasero seg fault).
it's a CD writer(and rewriter)/DVD reader.
Comment 15 aginies 2009-04-06 14:47:08 UTC
fcrozat built a new package with your patch (3mdv2009.1), but it seems this doesnt fix the brasero's seg fault.

-------------------
(gdb) exec brasero
(gdb) run
Starting program: /usr/bin/brasero 
[Thread debugging using libthread_db enabled]
[New Thread 0xb69c76e0 (LWP 318)]
Detaching after fork from child process 357.
[New Thread 0xb6645b90 (LWP 358)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6645b90 (LWP 358)]
brasero_medium_init_real (object=0x91b7938, handle=0x92de9d0) at brasero-medium.c:1318
1318                    priv->rd_speeds [i] = BRASERO_GET_32 (desc [i].rd_speed);
Missing debug package(s), you should install: bug-buddy-debug-2.26.0-1mdv2009.1.i586 elfutils-debug-0.140-1mdv2009.1.i586 gcc-debug-4.3.2-5mnb2.i586 ia_ora-gnome-debug-1.0.20-2mdv2009.1.i586 libcanberra-debug-0.11-3mdv2009.1.i586 libogg-debug-1.1.3-4mdv2009.0.i586 libtool-debug-2.2.6-6mdv2009.1.i586 libvorbis-debug-1.2.0-4mdv2009.0.i586
(gdb) thread apply all bt

Thread 2 (Thread 0xb6645b90 (LWP 358))

  • #0 brasero_medium_init_real
    at brasero-medium.c line 1318
  • #1 brasero_medium_probe_thread
    at brasero-medium.c line 3001
  • #2 g_thread_create_proxy
    at gthread.c line 635
  • #3 start_thread
    from /lib/i686/libpthread.so.0
  • #4 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 130
No symbol "desc" in current context.
--------------------
Comment 16 Philippe Rouquier 2009-04-06 19:26:37 UTC
@aginies@gmail.com:
Please could you run brasero like this:
brasero -g --brasero-media-debug > log 2>&1

do your stuff (make it crash)
and then attach the file called log that is in the directory where you started brasero to this bug.

Also would you see any inconvenience in building brasero from source? That way I could send you patches to add more debug.

Thanks in advance
Comment 17 aginies 2009-04-06 19:46:18 UTC
Created attachment 132213 [details]
brasero -g --brasero-media-debug
Comment 18 aginies 2009-04-06 19:48:46 UTC
(In reply to comment #16)
> Also would you see any inconvenience in building brasero from source? That way
> I could send you patches to add more debug.

no problem.
just send me the patch.
Comment 19 Philippe Rouquier 2009-04-07 09:26:49 UTC
@aginies@gmail.com:
I added the extra debugging to stable branch to get the values I want to monitor.
So since you said you could build from source, could give a try to SVN stable branch (gnome-2-26) please?
Thanks in advance.
Comment 20 aginies 2009-04-07 10:26:36 UTC
Created attachment 132253 [details]
brasero -g --brasero-media-debug

brasero was able to start !
Comment 21 aginies 2009-04-07 10:28:28 UTC
i was able to start brasero with:
---------
brasero -g --brasero-media-debug > log 2>&1
---------


but if a try to start it without debug mode, brasero seg fault...:
---------
[guibo@localhost brasero-gnome-2.26]$ /usr/local/bin/brasero 
Segmentation fault
---------

do you need a gdb output ?
Comment 22 Philippe Rouquier 2009-04-07 12:05:39 UTC
It's all right I think I got it. Thanks for the help.
Yet, I'm still puzzled by what I found out and I'd need some explanations about it from a compilation or C guru.

It turns out that the error is in this part:

int size = 0;
int num_desc, i;

[...]

num_desc = (size - sizeof (BraseroScsiGetPerfHdr)) / sizeof (BraseroScsiWrtSpdDesc);

Then if size < sizeof (BraseroScsiGetPerfHdr) - as is the case for you - then instead of setting a correct sign (negative) value for num_desc, it handles the value as if it was an unsigned integer which means an overflowing positive value. Now I thought that when you declared a variable as "int" it implied a signed value but apparently it does not.

So what is your compiler?? and your architecture?? (just out of curiosity)

Anyway I think I fixed it properly by simply checking 
if (size > sizeof (BraseroScsiGetPerfHdr) + sizeof (BraseroScsiWrtDesc)) which avoids all problems with sign.

That should do the trick.
Please test svn stable.
Thanks in advance.
Comment 23 aginies 2009-04-07 12:14:18 UTC
> So what is your compiler?? and your architecture?? (just out of curiosity)
-----------
[guibo@localhost brasero-gnome-2.26]$ gcc --version
gcc (GCC) 4.3.2
[guibo@localhost brasero-gnome-2.26]$ uname -a
Linux localhost 2.6.29-desktop-1mnb #1 SMP Thu Mar 26 02:43:20 BRT 2009 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux
-----------

i just update the branch and build brasero.
It works well without any seg fault \o/.

Thanks a lot for the fix :)
Comment 24 Philippe Rouquier 2009-04-07 12:23:07 UTC
Great news. My pleasure =). Your being fast and helpful in answering my requests made it a lot easier.

Sorry about that but could you get me a log please with simply
"brasero --brasero-media-debug > log"
I tried to fix the signed unsigned situation in another way. I'd really like to understand what's wrong here. Thanks if you can.
Comment 25 aginies 2009-04-07 12:26:15 UTC
Created attachment 132263 [details]
brasero --brasero-media-debug > log
Comment 26 Philippe Rouquier 2009-04-07 13:00:04 UTC
Thanks a lot for your help.

The fix has been cleaned in stable and committed to trunk.

Now since everybody has nautilus working now I think it's time to close it. Feel free to reopen it if it happens again. Thanks again.
Comment 27 Ian! D. Allen 2009-04-07 13:23:55 UTC
/* C promotes int to unsigned when mixed.  Not what one might expect ... */

#include <stdio.h>
main(){
    printf("%u\n", -1 );                   /* out: 4294967295 */
    printf("%u\n", -2 );                   /* out: 4294967294 */

    printf("%d\n", -2 / ((unsigned) 3) );  /* out: 1431655764 */
    printf("%d\n", -2 / ((signed) 3) );    /* out: 0 */

    printf("%d\n", -2 / ((unsigned) 2) );  /* out: 2147483647 */
    printf("%d\n", -2 / ((signed) 2) );    /* out: -1 */

    printf("%d\n", -2 / ((unsigned) 1) );  /* out: -2 */
    printf("%d\n", -2 / ((signed) 1) );    /* out: -2 */

    printf("%d\n", ((unsigned) 4294967295) / -2 );  /* out: 1 */
    printf("%d\n", ((unsigned) 4294967294) / -2 );  /* out: 1 */
    printf("%d\n", ((unsigned) 4294967293) / -2 );  /* out: 0 */

    return 0;
}
Comment 28 Philippe Rouquier 2009-04-07 13:38:30 UTC
and I guess the result of sizeof () in that case would be defined as unsigned which would explain the problem. Thanks a lot for your explanation.

What is strange still is that on my computer (running fedora), I don't have that problem when I hardcode size to 4 (which after the substraction should yield a negative value) in the failing code above. I do have a negative value as I should. It's weird that on some computers we have a negative value and on some others a positive value; and I checked I have the same compiler, same version..????
Comment 29 Ian! D. Allen 2009-04-07 14:59:44 UTC
Yes, it's unsigned, but "Whether the result of sizeof is unsigned int
or unsigned long is implementation defined."

http://publications.gbdirect.co.uk/c_book/chapter5/sizeof_and_malloc.html

If you use a machine where sizeof(unsigned long) > sizeof(unsigned int),
or where the size of the two structures differ, you will get different
results when the unsigned long result is stored back into a signed int.

On my i386, I have to use "long long" to show you what I mean:

#include <stdio.h>
int main(void){
    int size;
    int num_desc;
    unsigned long long i;

    printf("%d %d %d %d %d %d\n", sizeof(char), sizeof(short),
            sizeof(int), sizeof(long), sizeof(long long), sizeof(sizeof(int)));

    size = 7;
    for( i=1; i < 16; i++ ) {
        num_desc = (size - ((unsigned long long)8))
            / ((unsigned long long) i);
        printf("%d and %lld -> %d\n", size, i, num_desc);
    }

    return 0;
}

output:

1 2 4 4 8 4
7 and 1 -> -1
7 and 2 -> -1
7 and 3 -> 1431655765
7 and 4 -> -1
7 and 5 -> 858993459
7 and 6 -> -1431655766
7 and 7 -> -1840700270
7 and 8 -> -1
7 and 9 -> 1908874353
7 and 10 -> -1717986919
7 and 11 -> 1561806289
7 and 12 -> 1431655765
7 and 13 -> -1321528399
7 and 14 -> 1227133513
7 and 15 -> 286331153