i.MX6Q: glib segmentation fault

[Tarek]

When I'm loading the system with lots of video streams and running for long time glib is crashing with the same error message.

(<unknown>:3749): GLib-GObject-CRITICAL **: g_closure_invoke: assertion `closure->marshal || closure->meta_marshal' failed

GDB back trace is not always the same but here is the bt from last crash:

#0  0x2b8b58f0 in malloc_consolidate () from /lib/libc.so.6

#1  0x2b8b7064 in _int_malloc () from /lib/libc.so.6

#2  0x2b8b7f8c in _int_memalign () from /lib/libc.so.6

#3  0x2b8ba308 in memalign () from /lib/libc.so.6

#4  0x2b8bb8a0 in posix_memalign () from /lib/libc.so.6

#5  0x2aaf55a4 in av_malloc () from /usr/lib/libavutil.so

#6  0x2ac9efe4 in av_new_packet () from /usr/lib/libavcodec.so

#7  0x2abce1d8 in av_get_packet (s=0x36335580, pkt=0x39bfec10, size=3684) at libavformat/utils.c:269

#8  0x2ab460f0 in adbinary_mpeg (txtDat=0x39bfeb64, vidDat=0xa99700, pkt=0x39bfec10, s=0x8b9d70) at libavformat/adbinary.c:107

#9  adbinary_read_packet (s=0x8b9d70, pkt=0x39bfec10) at libavformat/adbinary.c:487

#10 0x2abce754 in av_read_packet (s=0x8b9d70, pkt=0x39bfec10) at libavformat/utils.c:735

#11 0x2abcf03c in av_read_frame_internal (s=0x8b9d70, pkt=0x39bfecd8) at libavformat/utils.c:1196

#12 0x000135d0 in player_thread (arg=0x869ce0) at player.c:425

#13 0x2b542290 in SDL_RunThread () from /usr/lib/libSDL-1.2.so.0

#14 0x2b56f600 in RunThread () from /usr/lib/libSDL-1.2.so.0

#15 0x2b5aab10 in start_thread () from /lib/libpthread.so.0

#16 0x2b90e958 in clone () from /lib/libc.so.6

#17 0x2b90e958 in clone () from /lib/libc.so.6

Can I upgrade to a more recent version of glib ?

[LeonardoSandova]

Hi Tarek,

have you tried to do this update through Yocto?

Are you doing some SW decoding/encoding (ffmpeg)?

In the order hand, to have a better backtrace info, It may be good if you do core dumps as suggested in this post

[Tarek]

Hi Leo,

I managed to upgrade to glib2-2.36.4 on LTIB. The system is much more stable but still crash after running for longer time.

Is Yocto more stable than LTIB now?

I'm using ffmpeg for demuxing the stream then feeding packets to gstreamer pipeline using appsrc.

I will try the core dumps but it takes many hours to hit the problem so bear with me.

[LeonardoSandova]

>I managed to upgrade to glib2-2.36.4 on LTIB. The system is much more stable but still crash after running for longer time.

>Is Yocto more stable than LTIB now?

Dylan branches are pretty stable so you can give it a try. I once did an upgrade (gstreamer) under LTIB and I remember it was a tough; with Yocto, it is just a matter of having the correct metadata; most of the time someone has already implemented it. So I strongly suggest to try Yocto. BTW, The yocto community is great. Are you using a Sabre SD board, right? Yocto has most of the Sabre SD machines.

> I'm using ffmpeg for demuxing the stream then feeding packets to gstreamer pipeline using appsrc.

Looking at the log, it seems that the crash is produced ffmpeg code (libavformat) so I wonder if this problem more generic. At this point, it would be good if you post log into the ffmpeg mailing list. In the other hand, is there any other non-ffmpeg demuxer you can use?

> I will try the core dumps but it takes many hours to hit the problem so bear with me.

Leo

[Tarek]

>Are you using a Sabre SD board, right? Yocto has most of the Sabre SD machines.

no, I'm using Nitrogen board and the build is failing with this error:

Log data follows:

| DEBUG: Executing shell function do_compile

| NOTE: make -j 4 CROSS_COMPILE=arm-poky-linux-gnueabi- CC=arm-poky-linux-gnueabi-gcc  --sysroot=/media/extradisk-1/data/extend_homes/telsherbiny/work/oe_fsl_t4/build-fb/tmp/sysroots/nitrogen6x nitrogen6X_config

| make: *** No rule to make target `nitrogen6X_config'.  Stop.

| make: *** [nitrogen6X_config] Error 1

>At this point, it would be good if you post log into the ffmpeg mailing list. In the other hand, is there any other non-ffmpeg demuxer you can use?

I have seen it crashing in the same glib2 function but the call was made from gstreamer not ffmpeg. I don't think it's ffmpeg problem.

I have to use ffmpeg demuxer because it's a modified version of ffmpeg that demux a proprietary stream. The work done to modify ffmpeg is not a trivial job to port to gstreamer.

Tarek

[LeonardoSandova]

On the building error, did you start building from an empty build folder?

if yes, then clean the package's sstate with

bitbake -c cleansstate <package name>

then bake again. If it fails again, send the issue to the meta-freescale list.

Yes, the crash was from gstreamer, that is for sure. the question is, which element is producing that crash? is it the ffmpeg demuxer? or a FSL element?