Jouni Karvo kirjoitti:
So it seems the syscall numbers have changed at some point. I am afraid
if the libc is now broken due to this. This has not happened to me
before, so I don't actually know what would be the good thing to do.
But forcing the syscall number to 178 does not actually fix
hi,
Reinhard Nissl kirjoitti:
Please report the logged error message.
Actually, your patch immediately segfaulted.
But I can see some problem: The include files from the distro tell me:
k...@vdr:/usr/include$ grep __NR_gettid */*
asm/unistd_32.h:#define __NR_gettid224
... and here the backtrace without -O2, if it helps more...
#0 0x004717be in cHashObject::Object (this=0x41) at tools.h:525
525 cListObject *Object(void) { return object; }
(gdb) bt
#0 0x004717be in cHashObject::Object (this=0x41) at tools.h:525
#1 0x00470153 in
Hi,
Am 26.01.2010 19:18, schrieb Jouni Karvo:
I included logs, please let me know what to try next.
Both of your so far posted logs show this scenario:
Jan 26 19:54:55 vdr vdr: [-1] buffer usage: 70% (tid=-1)
Jan 26 19:54:55 vdr vdr: [-1] buffer usage: 80% (tid=-1)
Jan 26 19:54:55 vdr vdr:
hi,
I just turned to 64bit, and it seems vdr dumps core there...
compiled with g++-4.3
command line:
`./vdr-prod -u vdr -w 60 -P xine -v /video0 -c /video0 --userdump -l 3'
log content (end of log):
Script done on Mon 25 Jan 2010 07:28:00 PM EET
Jan 25 19:26:20 vdr vdr: [-1] channel 1
Jouni Karvo kirjoitti:
hi,
I just turned to 64bit, and it seems vdr dumps core there...
compiled with g++-4.3
answering to myself. Compiling with g++-4.1 removes the segmentation fault.
I don't know whether this is related, but g++-4.3 warns in many places
about expressions with both
