Bug 307160 – [gst1394] gives an error when gst-register'ing

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 307160 - [gst1394] gives an error when gst-register'ing


Summary:	[gst1394] gives an error when gst-register'ing


Status:	RESOLVED FIXED

Product:	GStreamer
Classification:	Platform
Component:	gst-plugins
Version:	0.8.x
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	NONE
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2005-06-10 14:35 UTC by Michaël Arnauts
Modified:	2005-12-23 14:19 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Michaël Arnauts 2005-06-10 14:35:11 UTC

When i gst-register with the current CVS, i get this message:

Added plugin gst1394 with 1 feature.

(process:31635): GStreamer-CRITICAL **: gst_tag_register: assertion `info ==
NULL' failed

The other plugins are registered fine.

Comment 1 Ronald Bultje 2005-06-11 00:17:37 UTC

This is probably the next plugin. Can you run in gdb with --gst-fatal-warnings
and provide a backtrace?

Comment 2 Michaël Arnauts 2005-06-13 09:19:35 UTC

The next plugin is cdparanoia.

I have installed gstreamer debug packages, but it still doesn't give good
debugging information, do in need something more?

GStreamer-CRITICAL **: gst_tag_register: assertion `info == NULL' failed
aborting...

Program received signal SIGTRAP, Trace/breakpoint trap.
0xb7e802a8 in ?? ()
(gdb) bt full

+ Trace 60931

#0 ??
#1 ??
#2 ??
#3 ??
#4 ??
#5 ??
#6 ??
#7 pthread_mutex_init
from /lib/tls/i686/cmov/libc.so.6
#8 ??
#9 ??
#10 ??
#11 ??
#12 ??
#13 __PRETTY_FUNCTION__.6034
from /usr/lib/libglib-2.0.so.0
#14 ??
#15 ??
#16 ??
#17 __PRETTY_FUNCTION__.6034
from /usr/lib/libglib-2.0.so.0
#18 ??
#19 ??
#20 ??
#21 ??
#22 ??
#23 ??
#24 __PRETTY_FUNCTION__.6034
from /usr/lib/libglib-2.0.so.0
#25 ??
#26 _dl_runtime_resolve
from /lib/ld-linux.so.2
#27 ??
#28 ??
#29 __PRETTY_FUNCTION__.6034
from /usr/lib/libglib-2.0.so.0
#30 ??
#31 _dl_runtime_resolve
from /lib/ld-linux.so.2
#32 ??
#33 ??
#34 ??
#35 ??
#36 ??
#37 ??
#38 ??
#39 ??
#40 ??
#41 ??
#42 ??
#43 ??
#44 ??
#45 ??
#46 ??
#47 ??
#48 ??
#49 ??
#50 ??
#51 ??
#52 ??
#53 ??
#54 ??
#55 ??
#56 ??
#57 ??
#58 ??
#59 ??
#60 ??
#61 ??
#62 ??
#63 ??
#64 ??
#65 ??
#66 ??
#67 ??
#68 __elf_set___libc_thread_subfreeres_element___rpc_thread_destroy__
from /lib/tls/i686/cmov/libc.so.6
#69 __malloc_initialize_hook
from /lib/tls/i686/cmov/libc.so.6
#70 ??
#71 ??
#72 __PRETTY_FUNCTION__.9535
from /usr/lib/libglib-2.0.so.0
#73 ??
#74 ??
#75 ??
#76 ??
#77 ??
#78 ??
#79 ??
#80 ??
#81 ??
#82 ??
#83 ??
#84 ??
#85 ??
#86 ??
#87 ??
#88 ??
#89 ??
#90 pthread_mutex_unlock
from /lib/tls/i686/cmov/libc.so.6

Previous frame inner to this frame (corrupt stack?)

Comment 3 Luca Ognibene 2005-10-02 13:42:45 UTC

Are you able to replicate it with current packages?

See http://live.gnome.org/GettingTraces to see how provide a better backtrace!

Comment 4 Michaël Arnauts 2005-12-19 10:00:19 UTC

I guess this is fixed a long time ago...

Marking closed.