FS#23879 - [moc] symbol lookup error after the latest gcc-libs update

Attached to Project: Arch Linux
Opened by Heiko Baums (cyberpatrol) - Friday, 22 April 2011, 06:47 GMT
Last edited by Eric Belanger (Snowman) - Thursday, 19 May 2011, 04:47 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Eric Belanger (Snowman)
Allan McRae (Allan)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 9
Private No

Details

Description:
After quitting moc with Shift-Q I get this error message since the latest gcc-libs update:

mocp: symbol lookup error: /usr/lib/libstdc++.so.6: undefined symbol: _ZNSt14error_categoryD2Ev, version GLIBCXX_3.4.15

Anything else seems to work as usual. So I guess it's either an upstream issue or moc just needs to be rebuilt.
This task depends upon

Closed by  Eric Belanger (Snowman)
Thursday, 19 May 2011, 04:47 GMT
Reason for closing:  Fixed
Additional comments about closing:  moc-2.4.4-4
Comment by Stefan Schick (pommes_) - Monday, 25 April 2011, 08:41 GMT
I can confirm the Issue. I use moc-svn, version 2294-1 from AUR.
Comment by Juan Donadio (LoKi) - Monday, 25 April 2011, 11:32 GMT
Me too. I use moc 2.4.4-3 from Extra Repository.
Comment by Allan McRae (Allan) - Saturday, 30 April 2011, 23:17 GMT
Please test gcc{-libs}-4.6.0-4 in [testing]
Comment by Heiko Baums (cyberpatrol) - Sunday, 01 May 2011, 17:00 GMT
The issue is still there with gcc{-libs}-4.6.0-4 from [testing].
Rebuilding moc from ABS doesn't help either.
Comment by Daniel (aspala) - Sunday, 01 May 2011, 19:12 GMT
I also get this message, but not only after quiting mocp, but also when starting x server
I use Openbox as WM and just after "startx", everything goes fine, but when i take a look at TTY1, i get an endless list with this message, even if I had never started MOC
Comment by Allan McRae (Allan) - Sunday, 01 May 2011, 22:55 GMT
> readelf -s /usr/lib/libstdc++.so.6.0.16 | grep error_categoryD2Ev
3430: 0005f970 27 FUNC GLOBAL DEFAULT 13 _ZNSt14error_categoryD2Ev@@GLIBCXX_3.4.15

That symbol is there...
Comment by Juan Donadio (LoKi) - Thursday, 05 May 2011, 11:40 GMT
i recently upgrade to gcc-libs 4.6.0-4 from core and the symbol lookup error persists...any idea??
...moc works fine but this error is disturbing.
Comment by Allan McRae (Allan) - Saturday, 07 May 2011, 10:26 GMT
Can people seeing this tell me whether they are using i686 or x86_64?
Comment by Stefan Schick (pommes_) - Saturday, 07 May 2011, 10:34 GMT
I use x86_64
Comment by Eugene Arshinov (statc) - Saturday, 07 May 2011, 10:42 GMT
i686
Comment by Heiko Baums (cyberpatrol) - Saturday, 07 May 2011, 11:04 GMT
x86_64
Comment by Daniel (aspala) - Saturday, 07 May 2011, 15:06 GMT
x86_64
Comment by Juan Donadio (LoKi) - Saturday, 07 May 2011, 20:06 GMT
x86_64
Comment by Eric Belanger (Snowman) - Saturday, 07 May 2011, 20:20 GMT
That's plenty of confirmations. It happens on both arches. After reading a comment in the similar bug  FS#24122 , I realized that moc is written in c and doesn't even link to /usr/lib/libstdc++.so.6, So it looks like a gcc or glibc issue as other apps are also affected by this.
Comment by Rémy Oudompheng (remyoudompheng) - Saturday, 07 May 2011, 20:28 GMT
I confirm too. Actually /usr/lib/moc/decoder_plugins/libffmpeg_decoder.so is linked to libavformat.so which is linked to libstdc++.so.
Comment by Allan McRae (Allan) - Saturday, 07 May 2011, 23:29 GMT
I thought it might be an x86_64 only thing as I can not replicate on i686...
Comment by Eric Belanger (Snowman) - Saturday, 07 May 2011, 23:37 GMT
I don't have a i686 machine to test but I can replicate in my i686 chroot.
Comment by Rémy Oudompheng (remyoudompheng) - Sunday, 08 May 2011, 07:50 GMT
Debian pretends to have the bug fixed (they use a SVN snapshot)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623827

Here is the gdb report for this.

Reading symbols from /usr/bin/mocp...(no debugging symbols found)...done.
(gdb) break lt_dlexit
Breakpoint 1 at 0x804f034
(gdb) run -S
Starting program: /usr/bin/mocp -S
[Thread debugging using libthread_db enabled]
Running the server...
Trying JACK...
Trying ALSA...

Breakpoint 1, 0xb7c92030 in lt_dlexit () from /usr/lib/libltdl.so.7
(gdb) step
Single stepping until exit from function lt_dlexit,
which has no line number information.
0xb7b16103 in __libc_start_main () from /lib/libc.so.6
(gdb)
Single stepping until exit from function __libc_start_main,
which has no line number information.
/usr/bin/mocp: symbol lookup error: /usr/lib/libstdc++.so.6: undefined symbol: _ZNSt14error_categoryD2Ev, version GLIBCXX_3.4.15

Program exited with code 0177.
(gdb)
Comment by Jonathan D. (jonathand) - Sunday, 08 May 2011, 09:48 GMT
for those who want to get rid of this message until the issue is properly addressed, you can recompile the package from sources and disable the ffmpeg and musepack configure options (do not remove them, just replace the "--with-ffmpeg" with "--without-ffmpeg")
Comment by Rémy Oudompheng (remyoudompheng) - Sunday, 08 May 2011, 10:45 GMT
This is probably not desirable for a music player. However, the error message is totally innocuous and should not affect the correct behaviour of the program.
Comment by Jonathan D. (jonathand) - Sunday, 08 May 2011, 11:09 GMT
for those who want to get rid of this message until the issue is properly addressed, you can recompile the package from sources and disable the ffmpeg and musepack configure options (do not remove them, just replace the "--with-ffmpeg" with "--without-ffmpeg")
Comment by Jonathan D. (jonathand) - Sunday, 08 May 2011, 11:21 GMT
(sorry for the duplicate comment above)

@Rémy: the current issue is unfortunately not innocuous, as moc can be used non interactively from the command line and the exit codes always denotes an error in the current state (eg. "mocp -i" returns 127 instead of 0). Thus other applications or scripts build on top of moc may be broken.
I agree that users should be fine if moc is used interactively.
Comment by Allan McRae (Allan) - Tuesday, 10 May 2011, 11:30 GMT
We still need to figure out why this affects some people and not others. Can people who see this bug post their processor and what graphics card they are using?
Comment by Sébastien Martinez (Garrik) - Tuesday, 10 May 2011, 11:38 GMT
processor : Intel core 2 duo T5670
graphic card : ATI Mobility Radeon HD 3430
Comment by Juan Donadio (LoKi) - Tuesday, 10 May 2011, 14:32 GMT
Proc: AMD Phenom II X2 555 3.2ghz
Video: ATI Radeon HD4250 Onboard
Comment by Jonathan D. (jonathand) - Tuesday, 10 May 2011, 17:05 GMT
arch: i686
cpu: athlon xp 2500
gpu: nvidia geforce4 mx440
Comment by Daniel (aspala) - Tuesday, 10 May 2011, 18:32 GMT
arch: 64 bits
cpu: core2duo SU7300 1,3 ghz
gpu: intel 4500mhd integrated
Comment by Rémy Oudompheng (remyoudompheng) - Tuesday, 10 May 2011, 19:20 GMT
Allan: I don't see the relationship with CPU and GPU. Do you think we can safely ask users to downgrade glibc and see if the problem disappears?
Comment by Rémy Oudompheng (remyoudompheng) - Tuesday, 10 May 2011, 19:44 GMT
I propose a patch that made the message disappear for me.
   moc.patch (0.4 KiB)
Comment by Allan McRae (Allan) - Wednesday, 11 May 2011, 00:31 GMT
@Remy: I don't see the relationship to CPU/GPU either (clearly there is none with this bug) but I am struggling to see why it affects some people and not others...

Can you ping upstream with that patch? In fact, Debian claims to have fixed the issue with a SVN snapshot, so there may already be a fix upstream.
Comment by Rémy Oudompheng (remyoudompheng) - Wednesday, 11 May 2011, 04:54 GMT
Done. It would be great to have other users test the patch to check that it works as expected.
Comment by Jonathan D. (jonathand) - Wednesday, 11 May 2011, 06:20 GMT
I confirm the patch solves the issue (I'm using moc 2.4.4).
I'm a bit surprised we go for a patch against moc since the issue seems to affect other applications; but again, thanks for the fix.
Comment by Heiko Baums (cyberpatrol) - Wednesday, 11 May 2011, 06:28 GMT
Could you, please, tell me how you get it compiled? If I use the PKGBUILD from ABS I get "==> ERROR: options array contains unknown option 'force'". If I remove 'force' from the options array the source archive isn't untared and the directory can't be changed.
Comment by Rémy Oudompheng (remyoudompheng) - Wednesday, 11 May 2011, 06:29 GMT
I didn't read carefully enough libtool/dynamic loader documentation to decide whether:
- applications are broken and we were lucky it worked until some recent update of glibc/gcc-libs
- no, you don't need to dlclose() before dlexit() and dynamic loader is broken/too stupid to unload things properly.
Comment by Rémy Oudompheng (remyoudompheng) - Wednesday, 11 May 2011, 06:29 GMT
Heiko: you have to remove the force option and add "epoch=2" to the PKGBUILD
Comment by Heiko Baums (cyberpatrol) - Wednesday, 11 May 2011, 06:32 GMT
Rémy: Thanks, but just found out that it downloaded a 0 byte source archive for whatever reason. So I'll try it again.
Comment by Heiko Baums (cyberpatrol) - Wednesday, 11 May 2011, 06:39 GMT
I confirm, too, that the patch solves the issue.

Rémy: "epoch=2" is not necessary. It compiles without it.
Comment by Francisco (ffuentes) - Monday, 16 May 2011, 01:17 GMT
Me too. After updating my system right now and I'm having a issue with streaming links. Moc can't connect to streamings since my update (Other programs can do it).

I'm using Arch Linux in 32bits version, AMD Athlon 64x2
Comment by Eric Belanger (Snowman) - Monday, 16 May 2011, 02:07 GMT
Francisco: this isn't related to this bug. See  FS#23193 

Loading...