[ANNOUNCE] muggle 0.1.7

  • Tachauch,


    bin nun endlich dazu gekommen, mir mal die neueste muggle version zu kompilieren.


    Die Kompilierung lief nach Installation der libwrap0[-dev] auch wunderbar, aber ich kann weder mugglei ausfuehren noch das Plugin betreiben - vdr stuerzt ab.


    Ein strace zeigte mir, dass jeweils ein Segfault auftrat. Hier der backtrace:
    #0 0xb7d82fd3 in strlen () from /lib/tls/libc.so.6
    (gdb) bt
    #0 0xb7d82fd3 in strlen () from /lib/tls/libc.so.6
    #1 0x0805d97d in copy_arguments ()
    #2 0x0805e539 in mysql_server_init ()
    #3 0x08053b10 in mysqlhandle_t (this=0x83bf0f0) at mg_mysql.c:86
    #4 0x08053c77 in mgmySql (this=0x83bf154) at mg_mysql.c:106
    #5 0x0804f325 in mgDbGd (this=0x83bf150, separate_thread=false)
    at mg_sync.c:138
    #6 0x0804e671 in main (argc=15, argv=0xbffff714) at mugglei.c:164


    System:
    Debian Sid mit 2.6.9-1-k7, vdr 1.3.23, andere Plugins nur femon und dxr3 (brauche ich, da nur budget dvb-t drin).


    CMDLine args fuer vdr:
    -P'muggle -h gateway -u muggle -n music -p music -t /hosts/vdr/Music/By_Artist/Queens_of_the_Stone_Age'


    Hatte mal ein Verzeichnis relativ weit unten im baum genommen, da ich erst mal nur testen wollte - dafuer wollte ich aber jetzt nicht zigtausende files importieren und bei denen weiss ich, dass die Tags sauber sind ...


    Weiss jemand, was das sein koennte?


    [edit]
    Ist nur bei Benutzung von remote mysql - die embedded mysql tut's ...
    [/edit]


    Gruss


    /elle

    Einmal editiert, zuletzt von elle ()


  • Ich habe mir nun mal die Source von libmysqlclient12 und libmysqlclient14 geholt. Eigentlich kann es nur eine Erklärung geben: Du hast gegen libmysql 4.1.11 oder neuer kompiliert, aber beim Ausführen wird libmysql 4.0.X verwendet. Wenn meine Vermutung stimmt, müsste gdb Dir oben in mysqlhandle_t für argv_size den Wert -1 anzeigen. Damit stirbt er dann in copy_arguments, weil copy_arguments das als 65535 Argumente interpretiert. copy_arguments gibt es aber in 4.1.11 gar nicht mehr, also führst Du eine ältere Version aus. Und alles, was vor 4.1.11 liegt, ist nicht in der Lage, wahlweise embedded oder remote zu machen. Dass muggle mysqlhandle_t benutzt, sagt aber klar, dass gegen 4.1.11 oder neuer kompiliert wurde.


    Was sagen


    mysql_config --version
    ldd libvdr-muggle.so.1.3.wasauchimmer


    in Bezug auf mysql?


    Ich werde für die nächste Version von muggle dafür sorgen, dass er beim Ausführen mysql fragt, was da für eine Library läuft.


    EDIT: Habe ich nun gemacht, ist aber nicht immer sehr hilfreich, weil es die dafür nötige Funktion get_mysql_client_version() erst ab 4.1.1 gibt. Für 4.0.X weiss ich nicht, wie ich die Version beim Ausführen feststellen kann.

  • Moin,


    sitze jetzt leider nicht auch nur annaehernd in der Naehe des Rechners, so dass ich nicht nachschauen kann.


    Sind aber sid's Standard mysql-Pakete. Lt. http://packages.debian.org/ muesste der Server und die libmysqlclient ein 4.0.24 sein, da ich meine die libmysqlclient12[-dev]? installiert zu haben.


    Wenn ich HAVE_ONLY_SERVER setze, wird da auch gegen die "mitgebrachten" mysql libraries gelinkt (so hatte ich es aus der README verstanden, wenn HAVE_ONLY_SERVER nicht gesetzt wird) oder benutzt muggle dann nur die Systemlibraries? Vielleicht waere ein #define moeglich, ueber das gesteuert wird, welche Libs zu benutzen sind "HAVE_MYSQLDEV=1" oder nicht ...


    Gruss


    /elle

  • Zitat

    Original von elle
    Sind aber sid's Standard mysql-Pakete. Lt. http://packages.debian.org/ muesste der Server und die libmysqlclient ein 4.0.24 sein, da ich meine die libmysqlclient12[-dev]? installiert zu haben.


    das hatte ich ja vermutet, was den Ausführungszeitpunkt betrifft. Aber ich vermute eben auch, dass Du beim Kompilieren die Header von 4.1.11 installiert hattest, also libmysqlclient14-dev


    Zitat

    Wenn ich HAVE_ONLY_SERVER setze, wird da auch gegen die "mitgebrachten" mysql libraries gelinkt (so hatte ich es aus der README verstanden, wenn HAVE_ONLY_SERVER nicht gesetzt wird) oder benutzt muggle dann nur die Systemlibraries? Vielleicht waere ein #define moeglich, ueber das gesteuert wird, welche Libs zu benutzen sind "HAVE_MYSQLDEV=1" oder nicht ...


    beim Kompilieren wird nachgesehen, was installiert ist, und entsprechend kompiliert. Ohne HAVE_ONLY_SERVER kann man nur kompilieren, wenn mindestens 4.1.11 da ist. Beantwortet das Deine Frage?


    Siehe auch das Ende meiner vorherigen Message, habe ich nochmal editiert.

  • Ich seh mal nach, wenn ich heute abend dazu kommen, wenn's denn so ist, werde ich ein beherztes apt-get --purge remove libmysqlclient14-dev loslassen *g*


    Bzgl. Test, ob Funktion da ist:
    Ich kenn' mich mit C++ nicht aus, aber waere es nicht moeglich eine Art von (Pseudocode)


    Code
    if ( defined_function get_mysql_version)
      do_stuff_for_4.1
    else
      do_stuff_for_<4.1


    In PHP gibt's sowas, aber ich weiss nicht wie die's gemacht haben. Man muesste sich vielleicht mal die C-Sourcen der entsprechenden Funktion da ansehen. PHP ist ja eigentlich ein script-Frontend fuer C ... (uebertrieben ausgedrueckt)


    Gruss + Danke


    /elle

  • Zitat

    Original von elle
    Ich kenn' mich mit C++ nicht aus, aber waere es nicht moeglich eine Art von (Pseudocode)


    Code
    if ( defined_function get_mysql_version)
      do_stuff_for_4.1
    else
      do_stuff_for_<4.1


    C und C++ sind in diesem Punkt mit PHP nicht vergleichbar. Erstere betreiben ein striktes Typechecking beim Kompilieren (gut, C nicht so sehr...), PHP wird soviel ich weiss nur interpretiert. Der Interpreter weiss natürlich, was beim Ausführen da ist, der Kompiler weiss es nicht. Der Kompiler kann auch nicht den Linker fragen, weil Kompilieren und Linken strikt voneinander getrennt sind.

  • Ich glaube, wir haben uns da missverstanden.


    Mir ist schon klar, dass PHP "nur" eine interpretierte Sprache ist und Compilier und Linker komplett unabhaengig voneinander sind. Ich dachte nur, dass es irgendeine libc Funktion gaebe, um solche Dinge zu ueberpruefen - halt die "defined_function" ...


    Aber wie ueberprueft denn PHP dann zur Laufzeit, ob die Funktion verfuegbar ist? Registrieren die Module die Funktionen, die sie zur Verfuegung stellen in einer Tabelle oder so?


    Koennte man nicht - quasi wie nm es macht, schauen, ob ein bestimmtes Symbol verfuegbar ist, den Crash abfangen, wenn nicht, und entsprechend weitermachen? Irgendwie Signal 11 abfangen? Oder so?


    Gruss


    /elle

  • Bin ich wirklich der erste, dem dieses Problem begegnet ist?


    Gut - es ist wirklich merkwuerdig, gegen die 14er header zu kompilieren und dann aber gegen die 12er zur Laufzeit zu linken, aber theoretisch koennte das ja oefter passieren, oder?


    Auf einem System kompilieren, auf dem anderen ausfuehren, z.B. ...


    Gruss


    /elle


    P.S.: Ansonsten aber gute Arbeit - weiter so!!!

  • Zitat

    Original von elle
    Koennte man nicht - quasi wie nm es macht, schauen, ob ein bestimmtes Symbol verfuegbar ist, den Crash abfangen, wenn nicht, und entsprechend weitermachen? Irgendwie Signal 11 abfangen? Oder so?


    Das weiss ich nicht, aber es hört sich eher aufwändig an. Und evtl nicht portabel.

  • Zitat

    Original von LarsAC
    Um das zu erreichen müsste man den kompletten DB-Code in eine abstrakte Klasse auslagern und Subklassen für client12/client14 schreiben. Muggle müsste dann beim Start wählen, welche konkrete Klasse zu insanztiieren ist.


    Stimmt, das ginge natürlich. Das Auslagern ist in meiner Version bald fertig.
    Und das Instanziieren ist auch schon da:
    mgDb* GenerateDB(bool SeparateThread)
    {
    // \todo should return different backends
    return new mgDbGd(SeparateThread);
    }


    also bräuchte ich nur noch z.B. mgDbGd40 und mgDbGd41 von mgDbGd abzuleiten und nachsehen, welche Library installiert ist. Das wäre für mich das Hauptproblem: Wie machen, dass es auf alle Distris geht?

  • Zitat

    Original von elle
    Bin ich wirklich der erste, dem dieses Problem begegnet ist?


    Gut - es ist wirklich merkwuerdig, gegen die 14er header zu kompilieren und dann aber gegen die 12er zur Laufzeit zu linken, aber theoretisch koennte das ja oefter passieren, oder?


    Ich habe übersehen, dass die embedded library fest reingelinkt wird (libmysqld.a). Also müsstest Du beim Kompilieren/Linken libmysqld.a von libmysqlclient12 und die Header von libmysqlclient14-dev verwendet haben.

  • Habe mal in die mysql.h (v 4.0.23) geschaut und folgendes gefunden (weiss allerdings nicht, ob's implementiert ist ...):


    unsigned long STDCALL mysql_get_client_version(void);



    NB: Das ist nicht die Maschine, auf der der VDR laeuft, sondern mein Laptop ...


    Gruss


    /elle

  • Zitat

    Original von elle
    Habe mal in die mysql.h (v 4.0.23) geschaut und folgendes gefunden (weiss allerdings nicht, ob's implementiert ist ...):


    Das ist nur für die Standardlibrary definiert, nicht für embedded. Ich habe mir heute extra diverse Sourceversionen von mysql geholt, um nachzusehen. Für die embedded lib gibt es das wie gesagt erst ab 4.1.1

    Code
    wr@mm:~/Desktop$ grep -rw mysql_get_client_version mysql-dfsg*/*/*[ch]
    mysql-dfsg-4.0.24/include/mysql.h:unsigned long STDCALL mysql_get_client_version(void);
    mysql-dfsg-4.0.24/libmysql/libmysql.c:ulong STDCALL mysql_get_client_version(void)
    mysql-dfsg-4.0.24/libmysql_r/libmysql.c:ulong STDCALL mysql_get_client_version(void)
    mysql-dfsg-4.1-4.1.11/include/mysql.h:unsigned long     STDCALL mysql_get_client_version(void);
    mysql-dfsg-4.1-4.1.11/libmysqld/libmysql.c:ulong STDCALL mysql_get_client_version(void)
    mysql-dfsg-4.1-4.1.11/libmysql/libmysql.c:ulong STDCALL mysql_get_client_version(void)
    mysql-dfsg-4.1-4.1.11/libmysql_r/libmysql.c:ulong STDCALL mysql_get_client_version(void)
  • elle:
    Na wenns auf deinem VDR genauso aussieht ... irgendwo steht, daß man Embedded und External MySQL mit einem Binary erst ab Version 4.1.11 benutzen kann. Bei früheren Versionen ist je ein Binary mit HAVE_ONLY_SERVER=0|1 angesagt. Ich denke, damit ist die ganze Diskussion hier überflüssig.


    Gruß
    Mag1c

  • Mag1c:
    Das habe ich scheinbar uebersehen, aber eben im Changelog auf der Website folgendes gefunden:


    Zitat

    if you have mysql embedded 4.1.11 or better, you can access embedded and external data bases with the same binary. If you omit the -h parameter, embedded is used. Without embedded support compiled in, the default for -h is still localhost


    Ok, dann weiss ich Bescheid und werde HAVE_ONLY_SERVER=1 setzen, die 14-dev wegschmeissen (und bei Bedarf wieder installieren) und gut ist ...


    Danke noch mal


    Gruss


    /elle

  • Moin,
    Damit es beim Anlegen der Datenbanken ein bischen "deutscher" wird hier ein kleiner Patch:

  • So. Ich mal wieder. Also. Compiliert bekomme ich das ganze jetzt. Lag an meinen "sehr" eingeschränkten Kenntnissen in puncto Datenbanken. Bitte nicht hauen :D.


    Habe jetzt folgendes Problem :
    möchte, wie in der README steht, nach dem Kompilieren gerne mugglei -c ausführen, und bekomme dann immer die Fehlermeldung :
    vdr2:/usr/local/src/VDR/PLUGINS/src/muggle# mugglei -c

    Code
    vdr2:/usr/local/src/VDR/PLUGINS/src/muggle# mugglei -c
    050430 18:25:25 [ERROR] Character set information not found in '/usr/share/mysql/english/errmsg.sys'. Please install the latest version of this file.
    050430 18:25:25 [ERROR] Character set information not found in '/usr/share/mysql/english/errmsg.sys'. Please install the latest version of this file.
    Speicherzugriffsfehler



    Bitte nicht schalgen, da ich keine Ahnung von MySQL habe, aber würde doch so gerne mit muggle arbeiten

  • Zitat

    Original von grandmasterb10
    050430 18:25:25 [ERROR] Character set information not found in '/usr/share/mysql/english/errmsg.sys'. Please install the latest version of this file.[/CODE]


    das ist meiner Meinung nach ein Debian - Fehler. Die fragliche Datei ist dummerweise nur im Paket mysql-server, das musst Du auch installieren, auch wenn Du nur embedded nutzen willst.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!