Project

General

Profile

Bug #947

Crash on malloc() - git 2.99.15.g78213

Added by Tomas Matejicek over 12 years ago. Updated over 12 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2012-04-24
Due date:
% Done:

0%

Estimated time:
Found in version:
2.99.15.g78213
Affected Versions:

Description

Using latest tvheadend (todays git), it is crashing badly.

I can see this in error log: Unable to allocate 148224 bytes
The message comes from a fprintf in parse_mpeg2video() function
(parsers.c file), due to malloc() returning NULL for some reason.

I have 2GB free RAM and I am recording entire muxes at 3 adapters
at the same time for 24 hours a day (that is about 10 channels at once).

Tvheadend crashes usually after more than 20 hours of recording.

It seems it's going this way:
ts_recv_packet1() -> ts_recv_packet0() -> parse_mpeg_ts() -> parse_mpeg2video() -> malloc gets NULL here -> abort()

Why would it crash on malloc() is a mystery for me.
Is there any free() missing?
Could anybody skilled enough review the code?

One more notice:
after a fresh start, tvheadend forks about 20 processes, all are in state S (sleeping) most of the time, and recording works just fine. But after many hours, I can see some strange processes in T state (shown by htop, I have no idea what T should mean, htop help shows T=traced/stopped, but 'ps' doesn't report these processes). Surprisingly the processes won't go down, they seem to be locked by some futex, waiting for releasing some lock.

If there is anything I could provide for better debug, let me know please!

Thank you!


Files

gdb.txt (17.8 KB) gdb.txt debugger log as requested Tomas Matejicek, 2012-04-25 11:39

History

#1

Updated by Hein Rigolo over 12 years ago

a good gdb crash report is very helpful. Have a look at this page;
http://www.lonelycoder.com/redmine/projects/tvheadend/wiki/Tvheadendcrash

Hein

#2

Updated by Tomas Matejicek over 12 years ago

Since malloc() is a library function (libc?), not a function in tvheadend, is this debugger any useful? I will try to get the full debug, however it may take few days.

Here is the short log for now. The dirty flag is there since I added some printfs to the code earlier to track the bug, but rest assured the processing code of tvheadend and line numbers are completely preserved and untouched, the problem happens in clean tvheadend the very same way.

Unable to allocate 148224 bytes
[ALERT]:CRASH: Signal: 6 in PRG: ./build.linux/tvheadend (2.99.13.gcfa65.dirty) [28e434cbe38a5abcf1bc846a97dc2a08f4f4a30e] CWD: /usr/src/tvheadend..
[ALERT]:CRASH: Fault address 0x5256 (N/A)
[ALERT]:CRASH: Loaded libraries: /lib/i386-linux-gnu/librt.so.1 /lib/i386-linux-gnu/libdl.so.2 /usr/lib/i386-linux-gnu/libavahi-common.so.3 /usr/lib/i386-linux-gnu
[ALERT]:CRASH: Register dump [19]: 00000033 c15a0000 ffff007b ffff007b b74deff4 0826a8d0 b3a97970 b3a977f4 00005256 00000006 0000526c 00000000 00000000 00000000 b7
[ALERT]:CRASH: STACKTRACE
[ALERT]:CRASH: /usr/src/tvheadend/src/trap.c:139 0x8067872
[ALERT]:CRASH: __kernel_rt_sigreturn+0x0 ()
[ALERT]:CRASH: __kernel_vsyscall+0x10 ()
[ALERT]:CRASH: gsignal+0x4f (/lib/i386-linux-gnu/libc.so.6)
[ALERT]:CRASH: abort+0x175 (/lib/i386-linux-gnu/libc.so.6)
[ALERT]:CRASH: /usr/src/tvheadend/src/parsers.c:1099 0x805e7ae
[ALERT]:CRASH: /usr/src/tvheadend/src/parsers.c:332 0x805d0f3
[ALERT]:CRASH: /usr/src/tvheadend/src/tsdemux.c:122 0x805f887
[ALERT]:CRASH: /usr/src/tvheadend/src/tsdemux.c:256 0x805fd45
[ALERT]:CRASH: /usr/src/tvheadend/src/dvb/dvb_adapter.c:540 0x80849f8
[ALERT]:CRASH: ??:0 0xb74e9d4c
[ALERT]:CRASH: clone+0x5e (/lib/i386-linux-gnu/libc.so.6)

Please confirm this info is enough for you, or let me know to debug more.
Thank you

#3

Updated by Tomas Matejicek over 12 years ago

Update: Attached is the gdb.log file
Please let me know what else could I do to help you fix this annoying bug.
Thanks

#4

Updated by Adam Sutton over 12 years ago

  • Status changed from New to Rejected

Code has changed quite a bit since this report was made. If the problem still exists can you re-submit/open.

Also available in: Atom PDF