GNOME Bugzilla – Bug 584225
Crash in sanitize_path at sj-extracting.c:859
Last modified: 2012-05-24 13:52:49 UTC
Im' trying to rip a cd that is a live performance of a local deejay...so it is not in musicbrainz! I manually insert Author and CdName and Genre, but not tracks names because i don't know them!! Launching the extraction the shell reports: "MusicBrainz: Connecting to http://musicbrainz.org:80 MusicBrainz: GET /ws/1/release/?type=xml&discid=5UIikX68yEUH7mlXAC4icqtW3oY- MusicBrainz: Result: 0 (200 OK) MusicBrainz: Status: 200 MusicBrainz: Response: <?xml version="1.0" encoding="UTF-8"?><metadata xmlns="http://musicbrainz.org/ns/mmd-1.0#" xmlns:ext="http://musicbrainz.org/ns/ext-1.0#"><release-list></release-list></metadata> ** (sound-juicer:6866): WARNING **: Metadati incompleti per questo CD (sound-juicer:6866): Gtk-CRITICAL **: gtk_entry_set_text: assertion `text != NULL' failed (sound-juicer:6866): Gtk-CRITICAL **: gtk_entry_set_text: assertion `text != NULL' failed ** (sound-juicer:6866): CRITICAL **: musicbrainz_submit_message_area_new: assertion `title != NULL' failed (sound-juicer:6866): GLib-GObject-WARNING **: invalid (NULL) pointer instance (sound-juicer:6866): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** (sound-juicer:6866): CRITICAL **: gedit_message_area_set_default_response: assertion `GEDIT_IS_MESSAGE_AREA (message_area)' failed (sound-juicer:6866): Gtk-CRITICAL **: gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed Segmentation fault" If i add tracks name like "Tracks n" with n=1,2 it extracts correctly until it arrives at track n, and crashing with segnentation fault at track n+1. Thanks
Can you please run sound-juicer within gdb? Start a terminal, run "gdb sound-juicer", enter "run", crash it, type "thread apply all bt", post the output here as a new comment. Please make sure before that you have installed debug packages for glib2, gtk2 and sound-juicer.
Can confirm that segmentation faults occur when extracting CD:s where the names are unknown. Running gdb as described in comment #2 yields the following output: tyle:~$ gdb sound-juicer GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (gdb) run Starting program: /usr/bin/sound-juicer [Thread debugging using libthread_db enabled] [New Thread 0xb6884770 (LWP 11959)] [New Thread 0xb668bb90 (LWP 11965)] [Thread 0xb668bb90 (LWP 11965) exited] [New Thread 0xb5d50b90 (LWP 11967)] [New Thread 0xb43d3b90 (LWP 11969)] MusicBrainz: Connecting to http://musicbrainz.org:80 MusicBrainz: GET /ws/1/release/?type=xml&discid=F702xMOurFFDw_4M4Cxy2suE74s- MusicBrainz: Result: 0 (200 OK) MusicBrainz: Status: 200 MusicBrainz: Response: <?xml version="1.0" encoding="UTF-8"?><metadata xmlns="http://musicbrainz.org/ns/mmd-1.0#" xmlns:ext="http://musicbrainz.org/ns/ext-1.0#"><release-list></release-list></metadata> [Thread 0xb43d3b90 (LWP 11969) exited] (sound-juicer:11959): Gtk-CRITICAL **: gtk_entry_set_text: assertion `text != NULL' failed (sound-juicer:11959): Gtk-CRITICAL **: gtk_entry_set_text: assertion `text != NULL' failed ** (sound-juicer:11959): CRITICAL **: musicbrainz_submit_message_area_new: assertion `title != NULL' failed (sound-juicer:11959): GLib-GObject-WARNING **: invalid (NULL) pointer instance (sound-juicer:11959): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** (sound-juicer:11959): CRITICAL **: gedit_message_area_set_default_response: assertion `GEDIT_IS_MESSAGE_AREA (message_area)' failed (sound-juicer:11959): Gtk-CRITICAL **: gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6884770 (LWP 11959)] sanitize_path (str=0x0, filesystem_type=0x8f6ccd8 "ext3/ext4") at sj-extracting.c:859 859 sj-extracting.c: No such file or directory. in sj-extracting.c (gdb) thread apply all bt
+ Trace 216161
Thread 1 (Thread 0xb6884770 (LWP 11959))
A similar bug seem to be reported against Fedora 11. See https://bugzilla.redhat.com/show_bug.cgi?id=498764
Same thing for me, but not with empty tracks, with tracks name with exotic character. Choosing "Remove special characters" do not solve the problem. Must manually rename the tracks (if possible) to workaround
same issue on Ubuntu: https://bugs.edge.launchpad.net/sound-juicer/+bug/412800
related? https://bugzilla.gnome.org/show_bug.cgi?id=581775
*** Bug 609369 has been marked as a duplicate of this bug. ***
*** Bug 593534 has been marked as a duplicate of this bug. ***
Is someone going to confirm this so it can get fixed, or are there so few of you that you don't bother?
If I'm not mistaken, this issue should be fixed in sound-juicer-2.28.1
(In reply to comment #10) > If I'm not mistaken, this issue should be fixed in sound-juicer-2.28.1 So where's the patch? It's not even confirmed yet. Right?
*** Bug 615373 has been marked as a duplicate of this bug. ***
*** Bug 572145 has been marked as a duplicate of this bug. ***
I'm going to assert that this Gnome bug should cover sound-juicer crashing upon *any* empty metadata field in the UI; track name or artist or whatever. As such, I'll mark the 13 Ubuntu bugs that describe this same problem as dups of this bug. And no, this is not fixed in 2.28.1; Ubuntu Lucid has that (2.28.1-2) and that's where I first experienced this bug, although I can't work out how to repro it right now (I manually blanked out artist/album/track names and couldn't repro; perhaps it's only where they were also initially empty)?
I scrubbed the sound-juicer bugs in launchpad, and this bug has been reported against various Ubuntu version 17 times. They're now all marked as duplicates of launchpad bug 329809.
(In reply to comment #15) > I scrubbed the sound-juicer bugs in launchpad, and this bug has been reported > against various Ubuntu version 17 times. They're now all marked as duplicates > of launchpad bug 329809. 329809 is the wrong bug, on another application. Where are the dupes? And why isn't this bug either (1) marked as a dupe or (2) CONFIRMED?
P.S., if everything's getting duped against this UNCONFIRMED bug, how is it going to get fixed? And why isn't this marked CRITICAL?
UNCONFIRMED/CONFIRMED bugs are generally treated the same, so it's not big deal if this bug isn't CONFIRMED. As for marking it as critical, it's up to the application maintainer/the release team. Fwiw, bug #593534 and the ubuntu one have usable backtraces. I assume this bug is still reproduceable with sound-juicer 2.28.2?
Looks to me that the TrackDetails structure created in sj-metadata-musicbrainz3.c can contain a NULL "title" field, which would then cause that crash. Though I can't reproduce the crash and am not really familiar with the code, so maybe this has nothing to do with that. Anybody who can reproduce and can look into it?
VanillaMozilla, Bug 329809 is the correct bug. Please note that it's a launchpad.net bug, not a Gnome Bugzilla bug; see https://bugs.launchpad.net/ubuntu/+source/sound-juicer/+bug/329809
In comment 14, I mentioned I was having trouble repro'ing this. I've found a guaranteed way now: 1) Disable networking. This ensures that no CDDC/MusicBrainz/... lookup will succeed. 2) Run sound-juicer 3) Insert CD 4) Note that the sound-juicer bar displays "Retrieving track information...please wait", and that this doesn't go away 5) Now press Extract (all metadata is empty) 6) Instant crash If I fill in (album) title and (album) artist between steps 4 and 5 above, there's still a crash. If I additionally fill in track 1 title, then track 1 rips OK, but there's a crash when track 2 is processed. Finally, I believe the "no network" setting required to repro this is essentially the same as having the network up, but not managing to find anything on CDDB/MusicBrainz/... I think the first CD I ripped where I had this issue doesn't repro the issue any more because I actually added it to MusicBrainz. Hope this helps...
Yes, this still happens on 2.28.2, locally built from source on fully up-to-date Ubuntu Lucid. Program received signal SIGSEGV, Segmentation fault. sanitize_path (str=0x0, filesystem_type=0x827f410 "ext3/ext4") at sj-extracting.c:860 860 while (*str == '.')
+ Trace 221467
Thread 1 (Thread 0xb7fcd730 (LWP 7763))
Created attachment 159142 [details] [review] debug patch Since you compiled it from source and can reproduce the bug, could you reproduce it with this patch applied, and copy and paste the output as well as the backtrace? It would be even better if you could build with make CFLAGS="-g3 -ggdb3 -O0" (though it's not really important). Thanks!
I can reproduce it too now, I added 127.0.0.1 musicbrainz.org to /etc/hosts instead of putting down the network
Created attachment 159192 [details] [review] fixes the crash for me A small issue remains, the network is down (musicbrainz couldn't be reached), but it still suggests to send the CD info to musicbrainz.
Created attachment 159201 [details] [review] wrap access to AlbumDetails/TrackDetails in accessors 1/3
Created attachment 159202 [details] [review] wrap access to AlbumDetails/TrackDetails in accessors 2/3
Created attachment 159203 [details] [review] wrap access to AlbumDetails/TrackDetails in accessors 3/3 These 3 patches add accessors to TrackDetails/AlbumDetails to make sure we get a proper default value when needed. This feels more maintainable long-term than doing it in every metadata backend (and I suspect bad things might happen currently in the musicbrainz3 backend).
*** Bug 574678 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > VanillaMozilla, Bug 329809 is the correct bug. OK, I see it now. Bugzilla makes it an active link that points to the wrong bug. (In reply to comment #18) > As for marking it as critical, it's up to the > application maintainer/the release team. Right, but the bug report is almost a year old, and the application doesn't work at all for many people. Thanks, it's good to see some action on it.
(In reply to comment #30) > Right, but the bug report is almost a year old, and the application doesn't > work at all for many people. So what? People do work on it on their free time, so if a bug doesn't get fixed quick enough, the best course of action is often for someone impacted to look into fixing it, not to demand on a bug report that it gets fixed right now.
Sorry, I'm not trying to be demanding, but the appearance was that the bug might have fallen through the cracks and hadn't been noticed. I can't peer through the monitor and see whether someone is working on it. Note that the first reply told me that it was fixed already. (In reply to comment #31) > ...if a bug doesn't get fixed > quick enough, the best course of action is often for someone impacted to look > into fixing it, not to demand on a bug report that it gets fixed right now. Well, um, the reality is that most people need something that works immediately, so they uninstall it and use another program. There are too many programs to jump in and try to fix every bug (that someone else might already be working on).
Someone said he thought the issue was fixed in 2.28.1, in such cases, the best thing to do it to test it and to tell in the bug report if it's still happening for you or not.
(In reply to comment #33) > Someone said he thought the issue was fixed in 2.28.1, in such cases, the best > thing to do it to test it and to tell in the bug report if it's still happening > for you or not. Well, OK, I owe you an explanation, and maybe a friendly suggestion. Sorry for the bug spam and the long, lecturing tone. Takes too much time to make it warm and fuzzy. Maybe in an ideal world I'd try testing a nightly, but here's what actually happened. I found out that sound-juicer doesn't work. I dumped it and found something that does work. I eventually got around to reporting it. But I don't have time to fix every program that try, because there are too many of them. For me, trying a nightly in Linux is a project. And it wasn't fixed, was it? It's common to see programs that go for years with terrible bugs that get no attention. So when I see (1) a program that doesn't work; (2) bugs being duped against that one; (3) a critical bug with "normal" severity; and (4) no activity in a year except apparently for some "me too" comments, I have to assume that maybe all the reports might be getting unintentionally flushed. I did notice the "blocking" status, but I've heard that one before. This is not a small thing. While this may be a minor error to some, but it's also the default ripping program in the most popular Linux distro, and it crashes. My suggestion is for people to pay some attention to those fields in Bugzilla, or else not to be surprised by inquiries. It would have been easy for whoever confirmed this to mark it as CONFIRMED, and maybe even mark it critical. I know it's hard to catch all the dupes, but it's probably a dubious practice to dupe against a bug that hasn't been confirmed. I noticed that activity started less than an hour after I made a fuss for the third time. Did that have anything to do with it? Would it have been better if I have ignored it? Thanks for fixing this. :-)
This wasn't about testing a nightly, this was about testing the latest release of software, where someone reasonably thought the bug might be fixed. Mistakes happen, that's why a confirmation whether this bug was fixed was needed by people who can reproduce it. Because while this bug may seem important to you, ..., it's not happening for hundreds of people. So it's critical to *you* because you hit it easily, but not critical to many people since it simply doesn't happen for them. Once again, CONFIRMED/UNCONFIRMED doesn't really matter, bugs are treated the same whichever their state is. And it's debatable whether a crash happening to a few people deserve "critical" priority or not... Especially if it's not reproduceable. Activy happened on this bug after someone explained nicely *how* to reproduce the bug, not because of your whining. And I'm not asking you of fixing anything, just of giving productive feedback (eg "sorry, I can't test 2.28.2 just yet since it's not in my distro", or "I tested 2.28.2 but the bug is unfortunately sstill happening")
Created attachment 159333 [details] [review] Remove cdio metadata backend It's broken, and its license is not compatible with sound-juicer's anyway, so disable it. The gvfs backend already knows how to get CD-Text metadata, and provide fallbacks.
Pushed to master and gnome-2-28. The CD-Text backend shouldn't ever be compiled. libcdio is GPL, and sound-juicer requires GPL + exception or LGPL libraries. Let me know whether you can reproduce the problem when sound-juicer isn't (incorrectly) linked with libcdio, or with the patch above. I should note that all versions of Ubuntu (and probably Debian) ship a sound-juicer that's got license clashes (so that bug as well).
I may well have time to test patches etc. tonight or soon. I see a variety of different patches etc. in recent comments. If testing is still required, could you please point out exactly which patches I should apply etc. Thanks.
(In reply to comment #38) > I may well have time to test patches etc. tonight or soon. I see a variety of > different patches etc. in recent comments. If testing is still required, could > you please point out exactly which patches I should apply etc. Thanks. The one in comment 36, or just use sound-juicer from git (either master or gnome-2-28 branches).
Tested with git master, and CD:s that would cause sound-juicer 2.28.1 to crash are now extractable. Fields that were empty are now automatically filled with "Unknown artist", " Track xx" etc. I am also unable to get it to crash by emptying these fields, so it looks like this bug is solved.
Thanks for testing, closing.
I tested with network down; sound-juicer fills in all the missing fields with something reasonable; no repro now, so confirmed fixed. I manually erased each field individually; still no repro now, so confirmed fixed. I then went through my CD stack to try and find a CD that simply couldn't be found on MusicBrainz, which is what I think is what caused the original bug report. With this CD, sound-juicer 2.28.1-2 in Ubuntu Lucid shows all metadata as blank, and crashes when I hit the extract button without filling it in. However, on the exact same system just running sound-juicer git HEAD from today: * If sound-juicer was open when the CD was inserted: It pops up the following error message: No dialog title Dialog text: Could not thread the CD\n\nSound Juicer could not read the track listing on this CD. Reason: Cannot access CD: Error while getting peer-to-peer dbus connection: The name :1.95 was not provided by any .service files. [Close button] After clicking [Close], no metadata or track listing is filled in. (The name mentioned in the error message varies each time) * If I start git HEAD sound-juicer after the CD is inserted, I see the track listing, with all metadata filled in with e.g. "Unknown Title", "Unkown Artist", etc. Is this symptom related to this bug at all, or something else?
(In reply to comment #42) <snip> > * If sound-juicer was open when the CD was inserted: It pops up the following > error message: > > No dialog title > > Dialog text: Could not thread the CD\n\nSound Juicer could not read the track > listing on this CD. Reason: Cannot access CD: Error while getting peer-to-peer > dbus connection: The name :1.95 was not provided by any .service files. > > [Close button] > > After clicking [Close], no metadata or track listing is filled in. That error message is libbrasero suckiness (and there's a bug filed for it, look for that error message). > (The name mentioned in the error message varies each time) > > * If I start git HEAD sound-juicer after the CD is inserted, I see the track > listing, with all metadata filled in with e.g. "Unknown Title", "Unkown > Artist", etc. > > Is this symptom related to this bug at all, or something else? It works as expected then.
Gentlemen, it's likely that there are two bugs, and the bug remains as described. Disconnecting from the network, as described in comment 21, does not produce the bug for me. However, the original procedure as described by Lord_Neo, produces the bug every time. I'm working with version 2.28.1, but I strongly suggest you test again with the repaired version, using Lord_Neo's actual procedure.
Quite by accident I happen to have gotten version 2.31.6, and the bug DOES appear to have been fixed. It's odd that an old version passed the procedure in comment 21 but failed the procedure in comment 0. Doesn't matter, I guess. Closed as far as I'm concerned.
Got the bug, in version 3.4.0. Trace ===== ``` $ gdb sound-juicer GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>... Reading symbols from /usr/bin/sound-juicer...(no debugging symbols found)...done. (gdb) r Starting program: /usr/bin/sound-juicer [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffec4c9700 (LWP 18441)] [New Thread 0x7fffebac2700 (LWP 18442)] [New Thread 0x7fffea64e700 (LWP 18443)] [New Thread 0x7fffe9819700 (LWP 18444)] [Thread 0x7fffea64e700 (LWP 18443) exited] [New Thread 0x7fffea64e700 (LWP 18445)] [Thread 0x7fffe9819700 (LWP 18444) exited] [New Thread 0x7fffe9819700 (LWP 18455)] [New Thread 0x7fffda6b1700 (LWP 18456)] [New Thread 0x7fffd9eb0700 (LWP 18457)] [New Thread 0x7fffd96af700 (LWP 18458)] [New Thread 0x7fffc6a1e700 (LWP 18459)] [New Thread 0x7fffc4d7d700 (LWP 18464)] [Thread 0x7fffd96af700 (LWP 18458) exited] [Thread 0x7fffe9819700 (LWP 18455) exited] [Thread 0x7fffda6b1700 (LWP 18456) exited] [Thread 0x7fffd9eb0700 (LWP 18457) exited] Unrecognised release group element: 'primary-type' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised release group element: 'primary-type' [Thread 0x7fffc6a1e700 (LWP 18459) exited] (sound-juicer:18438): Gtk-CRITICAL **: gtk_icon_set_render_icon_pixbuf: assertion `icon_set != NULL' failed [187 identical lines omitted] Unrecognised release group element: 'primary-type' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised track element: 'number' Unrecognised release group element: 'primary-type' [Thread 0x7fffc4d7d700 (LWP 18464) exited] (sound-juicer:18438): Gtk-CRITICAL **: gtk_icon_set_render_icon_pixbuf: assertion `icon_set != NULL' failed [20 more] [Thread 0x7fffea64e700 (LWP 18445) exited] (sound-juicer:18438): Gtk-CRITICAL **: gtk_icon_set_render_icon_pixbuf: assertion `icon_set != NULL' failed [20 more] Program received signal SIGSEGV, Segmentation fault. 0x0000000000416947 in ?? () (gdb) thread apply all bt
+ Trace 230261
Thread 1 (Thread 0x7ffff7fb6980 (LWP 18438))
In fact, (1) SJ can't find the track names on MusicBrainz, even if they're there; and (2) given no title, it crashes trying to write "nowhere" (hypothesis)
1) is a caused by a libmusicbrainz4 bug (fixed in 4.0.2 or newer) 2) if you can reproduce the bug, a backtrace with gtk+, glib, gobject and sound-juicer debugging symbols installed would be very helpful.
Indeed, this happened on libmusicbrainz 4.0.0 (packaged in Ubuntu Precise)