Abstürze (nicht durch controld-zapit-merge!) >> Fehlersuche

[seife]

oder probier mal das: infoviewer-maybe-crashfix.diff

Ist das im Lichte meines letzten backtraces noch aktuell?

Ich bin mir nicht sicher. Schaden kann es nichts, aber ob es hilft mag ich nicht beurteilen.

PS: Gibt es ein gdbserver/gdb-ähnliches Konstrukt auch für Valgrind?
"gdb neutrino" auf der Dbox funktionierte nicht, wenn mit
--disable-flashrules kompiliert wurde, selbst auf meiner 64MB-Box,
aber mit gdbserver habe ich es nach einigen Anläufen gut hinbekommen,
ich werde mein Vorgehen zur Erlangung des obigen backtraces noch
dokumentieren.

Das wäre gut. Ich habe mit remote-gdb bisher nie einen ordentlichen Backtrace bekommen, insofern wäre ich daran sehr interessiert
Für Valgrind gibt es, soweit ich weiss, keinen server/client. Wenn ich das richtig kapiert habe, wird bei Valgrind das Programm teilweise in einer Art "emulation" ausgeführt: alle Funktionen, die mit Speicher zu tun haben (malloc, new, ... aber auch statische Variablen etc) werden durch Valgrind-funktionen ersetzt, die sich merken, wann wo warum und von wem der Speicher alloziert, dealloziert etc. wurde. Durch diesen Overhead ist es dann auch sehr langsam und benötigt sehr viel Speicher (der Prozessor der TD ist viermal so schnell wie der der dbox, und sie hat 64MB RAM, trotzdem dauert das starten von neutrino locker 1-2 Minuten und swap einzuschalten ist eine gute Idee). Aus diesem Grund halte ich den Einsatz von Valgrind auf der dbox für ein aussichtsloses Unterfangen.
Selbst auf der TD lassen sich manche sachen im Valgrind nicht testen. Der audioplayer z.B., der wohl relativ viel in den Dekodern im Speicher rumschiebt, "spielt" MP3's so etwa mit 1 sek / Minute ab, Ton ist da nicht wirklich zu hören
Der Movieplayer2 ging erstaunlich gut, aber nur im TS modus, wo er die daten mit wenig "zwischenstationen" direkt in den Dekoder schiebt, bei MPEGs, die er selbst parsed und in TS umwandelt, wird es schon sehr ruckelig. Auf der TD, nicht auf der dbox

Valgrind konnte ich noch nie auf der Dbox starten, es kam, afair,
immer eine floating point exception.

Das hört sich ja eher nach crosscompile-Problem an, aber es ist den Aufwand, das zu fixen vermutlich nicht wert.

Ein Grund, warum ich neutrino auch auf i386/x86_64 zum laufen gebracht habe (sehr experimentell, mit einem VNC-Server als Framebuffer-Ersatz ) war, dass ich auf einer schnellen Maschine solche Sachen wie den audioplayer auch im Valgrind debuggen kann. Allerdings muss es dazu erst mal akzeptabel laufen

[-=HSKc=-Robby]

Hab endlich nen Absturz mitloggen können, vielleicht hilft es ja (ist noch der CVS-Stand 25.03.09). Denke aber, dass es der gleiche Fehler wie bei dem Log von e30 ist:

Code: Alles auswählen

[controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (16:9 -> 4:3)
15:01:28.559 dmxCN: going to sleep...
15:01:28.561 eit_set_update_filter, servicekey = 0x4530001445c, current version 30
15:01:29.985 dmxCN: waking up again - requested from .change()
[zapit] tuned frequency does not match request. difference: 859
PES, queue 0 normal.
[controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (4:3 -> 16:9)
terminate called after throwing an instance of 'std::bad_alloc'
terminate called recursively
15:01:32.070 dmxCN: going to sleep...
15:01:32.071 eit_set_update_filter, servicekey = 0x43700016d67, current version 6
Aborted
zapit shot down :)
Waiting for timerd (max. 5 seconds)
Waiting for timerd (max. 4 seconds)
Waiting for timerd (max. 3 seconds)
Waiting for timerd (max. 2 seconds)
Waiting for timerd (max. 1 seconds)
   --------------------------------------------   
   ---   System wird heruntergefahren :)    ---   
   --------------------------------------------   
   --------------------------------------------   
   ---  shutdown.flash2x wird abgearbeitet  ---   
   --------------------------------------------   
   ---      Sectionsd wird angehalten       ---   
   --------------------------------------------   
setPauseScanning true
   --------------------------------------------   
   ---        suche nach Flash-Files        ---   
   --------------------------------------------   
   ---  es wurde KEIN Flash-File gefunden!  ---   
   --------------------------------------------   
   ---        shutdown.flash beendet        ---   
   --------------------------------------------   
   ---          halt.local beendet          ---   
   --------------------------------------------   
   ---      Shutdown wird fortgesetzt       ---   
   --------------------------------------------   
Going to halt system now ...
CXA2092 found
CXA2092 found
Waiting for automount (max. 5 seconds)
Unmounting 'xfs' on '/hdd'
Unmounting 'tmpfs' on '/tmp'
umount: can't umount /tmp: Device or resource busy
Unmounting 'jffs2' on '/var'
Ready to shutdown system...

The system is going down NOW!

Sending SIGTERM to all processes
[yhttpd] !!! SIGNAL !!! :15!
[yhttpd] No special SIGNAL-Handler:15!
[yhttpd] stop requested......

Sending SIGKILL to all processes

Requesting system halt
flushing ide devices: hda '

Bitte nicht über die ungewöhnlichen Einträge beim runterfahren wundern. Hab die halt.local so bearbeitet, dass ich die Box flashen kann, ohne direkt dabei sein zu müssen... Muss nur das flashfile in den tmp-Ordner schieben und die Box neu starten

[rhabarber1848]

ich werde mein Vorgehen zur Erlangung des obigen backtraces noch dokumentieren

Das wäre gut. Ich habe mit remote-gdb bisher nie einen ordentlichen Backtrace bekommen, insofern wäre ich daran sehr interessiert

EDIT: Dieses HowTo ist nun im Wiki zu finden:
GDB_einrichten
An diesem Posting werde ich keine Änderungen mehr vornehmen.

Na denn:

cdk/configure --disable-flashrules, damit alle Debugsymbole vorhanden sind
make yadd-neutrino gdb gdb-remote

In cdkroot/etc/init.d/start_neutrino hinter die Zeile

Code: Alles auswählen

nhttpd

folgendes einfügen:

Code: Alles auswählen

exit 0

weil wir Neutrino manuell starten werden.
Yadd booten.

Per Telnet auf die Dbox einloggen, dann:

Code: Alles auswählen

gdbserver :5555 neutrino

gdb wartet dann auf den connect eines clients:

Process neutrino created; pid = 189
Listening on port 5555

Auf dem Client ins Verzeichnis $prefix/cdk/bin wechseln und

Code: Alles auswählen

./powerpc-tuxbox-linux-gnu-gdb ../../cdkroot/bin/neutrino

Dann geht es los:

Code: Alles auswählen

target remote dbox:5555
continue

Wenn Neutrino abgestürzt ist, kann, wie gehabt, mit

Code: Alles auswählen

bt full

ein backtrace erzeugt werden.

EDIT 16.04.2009:
Folgende Optionen sind für powerpc-tuxbox-linux-gnu-gdb nicht mehr nötig:
http://article.gmane.org/gmane.comp.vid ... ox.scm/220

Code: Alles auswählen

set solib-search-path /home/tuxbox/work_glibc/image/cdkroot/lib
set sysroot /home/tuxbox/work_glibc/image/cdkroot/

[seife]

Mal 'ne ganz andere Spur...
Probier mal das:

Code: Alles auswählen

diff --git a/tuxbox/neutrino/lib/sectionsdclient/sectionsdclient.cpp b/tuxbox/neutrino/lib/sectionsdclient/sectionsdclient.cpp
index 44baeee..1af4037 100644
--- a/tuxbox/neutrino/lib/sectionsdclient/sectionsdclient.cpp
+++ b/tuxbox/neutrino/lib/sectionsdclient/sectionsdclient.cpp
@@ -339,7 +339,7 @@ bool CSectionsdClient::getCurrentNextServiceKey(const t_channel_id channel_id, C
                dp+= sizeof(event_id_t);
                current_next.current_zeit = *(CSectionsdClient::sectionsdTime*) dp;
                dp+= sizeof(CSectionsdClient::sectionsdTime);
-               current_next.current_name = dp;
+               current_next.current_name = std::string(dp);
                dp+=strlen(dp)+1;

                // next
@@ -347,7 +347,7 @@ bool CSectionsdClient::getCurrentNextServiceKey(const t_channel_id channel_id, C
                dp+= sizeof(event_id_t);
                current_next.next_zeit = *(CSectionsdClient::sectionsdTime*) dp;
                dp+= sizeof(CSectionsdClient::sectionsdTime);
-               current_next.next_name = dp;
+               current_next.next_name = std::string(dp);
                dp+=strlen(dp)+1;

                current_next.flags = *(unsigned*) dp;

Sonst gehen mir so langsam die Ideen aus

[rhabarber1848]

oder probier mal das: infoviewer-maybe-crashfix.diff

Der Absturz beim Extrem-Zapping ist damit weiterhin reproduzierbar.

[rhabarber1848]

- current_next.current_name = dp;
+ current_next.current_name = std::string(dp);

Ebenfalls erfolglos...

[rhabarber1848]

mit dem JtG-Snap vom 25.03.09

Welcher CVS-snap ist der letzte, der den Bug nicht aufweist?

[-=HSKc=-Robby]

Also bei dem Snap vom 18.03. ist mir noch nix aufgefallen...

Ich hatte Riker gebeten wegen dem controld-zapit-merge nen neuen Snap zu erstellen, damit die JtG-Gemeinde mittesten kann.

[seife]

Ich bin mir ziemlich sicher, dass es die memleak-Fixes sind. Die sind allerdings nicht schuld, denn der Bug ist vermutlich viel tiefer liegend.

Um den schuldigen commit genau zu bestimmen, müsste man es bisecten, das geht aber halt mit CVS nicht

[rhabarber1848]

Ich bin mir ziemlich sicher, dass es die memleak-Fixes sind.

Die sind doch erst ab dem 26.3. ins CVS gewandert, oder?
Der Fehler tritt aber schon im JTG-Image vom 25.3. auf.
Ich teste gerade ein Yadd (cvs -D 20090322), welches
also auf dem Stand vor dem controld-zapit-merge ist.
Mal sehen, wie das aussieht.

[rhabarber1848]

Ich teste gerade ein Yadd (cvs -D 20090322)

Der Absturz geschieht auch mit controld

[seife]

probier's mal noch mit dem 10. März - das war, vor ich die "delete vs delete []"-Sachen angefangen habe zu fixen.
Da wird es nicht crashen, dafür leaked es dann wieder.

[-=HSKc=-Robby]

Ich gehe mal auf den JtG-Snap vom 18.03. zurück, um dann zu schaun, ob es dort auch zu den Abstürzen kommt
Wenn es nur beim extrem-zappen auftreten würde, könnte man sich ja darauf einstellen. Aber da es ja auch beim normalen umschalten passieren kann, ist es schon ziemlich nervig...

[rhabarber1848]

probier's mal noch mit dem 10. März

CVS vom 09.03.2009 funktioniert problemlos, dann habe ich die
Patches vom 10.03. nach und nach eingespielt.

Diese Patches lösen den Absturz von Neutrino aus:
http://cvs.tuxbox-cvs.sourceforge.net/c ... 7&r2=1.249

[-=HSKc=-Robby]

probier's mal noch mit dem 10. März

CVS vom 09.03.2009 funktioniert problemlos, dann habe ich die
Patches vom 10.03. nach und nach eingespielt.

Diese Patches lösen den Absturz von Neutrino aus:
http://cvs.tuxbox-cvs.sourceforge.net/c ... 7&r2=1.249

Hört sich nach Fleißarbeit an
Schonmal Danke für die Mühe!!!

PS: Hab mal die Überschrift vom Thread geändert, da es ja nicht am controld-zapit-merge liegt.

[rhabarber1848]

Hört sich nach Fleißarbeit an

Nicht wirklich, das Erstellen der Patches war einfach,
dann nach jedem Patch "make neutrino" und wildes
Gehämmere auf der Fernbedienung, ging ziemlich
schnell.

[re_Look]

@rhabarber1848
Kannst du damit versuchen ? Am besten mit printf, damit du siehst ob das benutzt wird.

Code: Alles auswählen

RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/src/neutrino.cpp,v             
retrieving revision 1.942                                                 
diff -u -r1.942 neutrino.cpp                                              
--- a/neutrino.cpp      1 Apr 2009 11:44:36 -0000       1.942             
+++ b/neutrino.cpp      8 Apr 2009 15:47:23 -0000                         
@@ -2502,7 +2502,8 @@                                                     
                                                                          
        if (msg == CRCInput::RC_ignore)                                   
        {                                                                 
-               delete (unsigned char*) data;                             
+               delete [] (unsigned char*) data;                          
+               data=NULL;                                                
                return messages_return::handled;                          
        }                                                                 
                                                                          

[seife]

probier's mal noch mit dem 10. März

CVS vom 09.03.2009 funktioniert problemlos, dann habe ich die
Patches vom 10.03. nach und nach eingespielt.

Diese Patches lösen den Absturz von Neutrino aus:
http://cvs.tuxbox-cvs.sourceforge.net/c ... 7&r2=1.249

Super. Das ganze Gelumpe kommt mir schon immer etwas seltsam vor

Dann muss ich das irgendwie anders machen. Ich schau's mir am Freitag/Samstag an, vor ich in den Urlaub fahre...

Robby: sag doch Riker mal, er soll eine start_neutrino aus dem CVS nehmen. Dann wird nämlich neutrino einfach neu gestartet. Das ist zwar unschön, aber eine Sache von Sekunden und du musst nicht rebooten.

(Ja, ich versuche trotzdem den Bug zu fixen... ;-))

[rhabarber1848]

Kannst du damit versuchen ? Am besten mit printf, damit du siehst ob das benutzt wird.

Hat nicht funktioniert und wird auch nicht angesprungen.

[seife]

Das delete im RC_ignore-Zweig ist IMHO total falsch (weil RC_ignore keine Daten dabei haben sollte), das muss ich mir auch noch mal anschauen, ist mir auch schon aufgefallen.

rhabarber: Hilft es denn temporär, nur genau diese beiden Patches zu reverten? Dann würden wir im schlimmsten Fall ein paar bytes pro "epg-ist-da"-Event leaken, das ist aber im gegensatz zum crashen angenehmer.
Und ich mach mir dann gedanken über einen richtigen fix.

BTW: das rausfinden des relevanten Commits war sehr hilfreich, danke dafür.
Mir war zwar klar, dass es damit was zu tun haben muss, aber ich hätte auf der anderen Seite (beim delete[]) gesucht, ich bin immer davon ausgegangen, dass mein allozieren korrekt wäre ;-)
Nachdem es auch nur dann auftritt, wenn 2 solcher events in schneller Reihenfolge kommen, also der 2. kommt bevor der Erste "verarbeitet" ist, könnte es ein grundlegenderes Problem sein.
Ich habe vor, es so zu lösen, dass ich einfach _nicht_ mitschicke, welches event grad "current/next" getriggert wurde, denn _wenn_ das getriggert wird, ist "info_CN" oder wie die Variable heisst eh schon gesetzt.

...das schau ich mir aber übermorgen an...

[seife]

also "...temporär im aktuellen CVS genau diese beiden Patches zu reverten..."
(kannst du ja auch "von Hand" mit dem Editor machen, ist ja nicht viel).

[re_Look]

Auf dreambox läuft es aber problemlos, oder hat da auch jemand Probleme ?

[-=HSKc=-Robby]

Dann muss ich das irgendwie anders machen. Ich schau's mir am Freitag/Samstag an, vor ich in den Urlaub fahre...

Robby: sag doch Riker mal, er soll eine start_neutrino aus dem CVS nehmen. Dann wird nämlich neutrino einfach neu gestartet. Das ist zwar unschön, aber eine Sache von Sekunden und du musst nicht rebooten.

(Ja, ich versuche trotzdem den Bug zu fixen... ;-))

Hoffe Du beeinflußt deswegen nicht Deine Urlaubsvorbereitung

Also in den JtG-Images kann man unter /var/tuxbox eine eigene start_neutrino ablegen. Ist dort keine vorhanden, wird die "standart"-start_neutrino von /etc/init.d geladen. Die sieht derzeit so aus:

Code: Alles auswählen

#!/bin/sh
# JTG-Team-Image start_neutrino v1.06 #25.03.2009

if [ -x /var/bin/sectionsd ]; then
 /var/bin/sectionsd
else
 if [ -e /var/bin/sectionsd ]; then
  chmod +x /var/bin/sectionsd
  /var/bin/sectionsd
 else
  /bin/sectionsd
 fi;
fi;

/bin/timerd

if [ -e /var/bin/zapit ]; then
 if [ ! -x /var/bin/zapit ]; then
 chmod +x /var/bin/zapit
 fi;
fi;

if [ -e /var/bin/zapit ]; then  
    if [ -e /var/etc/.pmt_update ] ; then
     /var/bin/zapit -u
    else
     /var/bin/zapit
    fi;
else
    if [ -e /var/etc/.pmt_update ] ; then
     /bin/zapit -u
    else
     /bin/zapit
    fi;
fi;

if [ -x /var/bin/camd2 ]; then
 /var/bin/camd2
else
 if [ -e /var/bin/camd2 ]; then
  chmod +x /var/bin/camd2
  /var/bin/camd2
 else
  /bin/camd2
 fi;
fi;

if [ -e /var/etc/.kb2rcd ]; then
 if [ -x /var/bin/kb2rcd ]; then
 /var/bin/kb2rcd
else
 /bin/kb2rcd
 fi;
fi;

nhttpd
neutrino -u -f

pzapit -kill

i=5
while expr $i != 0 > /dev/null; do
 if pidof timerd > /dev/null; then echo "Waiting for timerd (max. $i seconds)"
 elif pidof zapit > /dev/null; then echo "Waiting for zapit (max. $i seconds)"
 else break;
 fi
 i=`expr $i - 1`
 sleep 1
done

if [ -e /var/tuxbox/halt.local ] ; then
 chmod +x /var/tuxbox/halt.local
 /var/tuxbox/halt.local
fi;

if [ -e /tmp/.reboot ] ; then
 /sbin/reboot
else
 echo "Going to halt system now ..."
 /sbin/halt
fi;

exit 0 

Sorry das ich frage , aber was in der start_neutrino aus dem cvs anders?

[rhabarber1848]

Hilft es denn temporär, nur genau diese beiden Patches zu reverten?

Genau genommen sind es ja drei Patches, die ich verlinkt habe.
Ja, das Entfernen dieser drei Patches aus dem aktuellen CVS
behebt das Problem, soeben getestet.

das ist aber im gegensatz zum crashen angenehmer.

Sehe ich genauso.

Nachdem es auch nur dann auftritt, wenn 2 solcher events in schneller Reihenfolge kommen, also der 2. kommt bevor der Erste "verarbeitet" ist, könnte es ein grundlegenderes Problem sein.

Ich beschreibe nochmal, was genau passiert:

Mit Null schnell zwischen zwei Sendern wechseln,
die Taste wird dabei 1-2x pro Sekunde gedrückt.
Zwischendurch drücke ich die Taste Acht, dabei
erscheint ein vierstellliges Zifferneingabefenster
und in der Infobar wird der EPG des Programms
auf dem Programmplatz Acht angezeigt. Um mit
dem Umschalten mittels Null fortfahren zu können,
drücke ich die Taste Home, dann wieder Null in
schneller Folge und hin und wieder die Acht.
Irgendwann nach dem Drücken der Taste
Acht, also dem Anzeigen des EPGs eines Senders,
zwischen dem ich mit Null nicht umgeschaltet habe,
stürzt Neutrino ab. Manchmal dauert es 1-2
Minuten, dabei alle 10 Sekunden einmal auf die
Acht gedrückt, bis der Fehler ausgelöst wird.

[rhabarber1848]

Sorry das ich frage , aber was in der start_neutrino aus dem cvs anders?

Fast alles, besonders

Code: Alles auswählen

until neutrino -f -u ; do
    echo "Neutrino exited with nonzero exit status, restarting..."