[vz-dev] vzlogger mit Landis&Gyr ehz

[Thorben Thuermer]

On Tue, 22 Jan 2013 11:53:03 +0100
Michael Wulz <michael.wulz at gmail.com> wrote:
> Am 22.01.13 09:52, schrieb Thorben Thuermer:
> > On Mon, 21 Jan 2013 21:38:56 +0100
> > Michael Wulz <michael.wulz at gmail.com> wrote:
> >> Ich habe einen Landis & Gyr EHZ (ZMD3 Serie).
> >> Wenn ich mit dem Test-Script von:
> >> http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/siemens_td3511
> >> Den Zähler auslese, bekomme ich folgende Daten:
> >> 6 Bytes written
> >> /?!
> >> /LGZ5\2ZMD3124.B14
> > [...]
> >> 1.8.1(23.1*kWh)
> >> 1.8.1*1(23.1)
> > [...]
> >> .9.1(7:42:7)
> >> .9.2(-1-18)
> >> .2.(B14)
> >> .2.1(TEST)
> >> .2.2(999)
> >> C.2.1(-1-1 :)
> >> C.9.1(AAAAAAA)
> > [...]
> Das folgende git:
> https://github.com/volkszaehler/vzlogger.git
[...]
> >> Wenn ich nun den vzlogger starte, kommt nach 10 Sekunden zirka ein
> >> Segmentation Fault:
> > [...]
> >> [Jan 21 21:37:06][meter_Segmentation fault
> >>
> >> An was kann das ganze liegen?
> > oben ist schon zu sehen, dass die ausgabe von deinem zaehler etwas
> > ungewoehnlich aussieht,
> > ich vermute damit kommt der d0-parser in vzlogger (der leider recht primitiv ist)
> > nicht klar.
> Denke auch, dass der Parser da den Segfault auslöst. Die OIDS sind 
> nämlich hier auch anders,
> ohne "1-0:" am Anfang.
> >
> > ich wuerde mir das nachher mal anschauen,
> > waehre gut wenn du die ausgabe des zaehlers einmal direkt wegspeichern
> > und als attachment schicken koenntest (damit enthaltene binaerdaten
> > erhalten bleiben),
> > dann kann ich das zum testen nehmen.
> Die Daten vom Zähler im Attachment "zaehlerdaten.txt"
> mit folgendem Befehl getriggert:
> # echo $'\x2f\x3f\x21\x0d\x0a' > /dev/ttyUSB0

gut!

> > noch besser waehre wenn du auch selber vzlogger mit configure --enable-debug
> > kompilierst, in gdb startest, und ein 'bt full' postest...
> hier der Output:
> 
> root at raspberrypi:/usr/local/etc# gdb vzlogger
> (gdb) run
> Program received signal SIGILL, Illegal instruction.
> 0xb6b0f4c0 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
> (gdb) bt full
> #0  0xb6b0f4c0 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
> Cannot access memory at address 0x0
> #1  0xb6b0bee4 in OPENSSL_cpuid_setup () from 
> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
> #2  0xb6fe8250 in ?? () from /lib/ld-linux-armhf.so.3
> #3  0xbefffe40 in ?? ()
> #4  0xbefffe40 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Ich kann da aber jetzt nix von einem Segfault sehen.
> ohne gdb wieder wie gehabt:

wie gdb schon sagt: "(corrupt stack?)",
der stack wurde durch den crash so sehr zerschossen,
dass kein sinnvoller backtrace mehr erzeugt werden kann.
(die libcrypto-funktion ist voellig unsinnig an der stelle,
 sind einfach nur zufallsdaten statt sinnvollen addressen)
(efence kann zB helfen, sowas zu verhindern,
 oder man muss halt einen breakpoint im parser setzen und dann im single-step
 modus weitermachen bis man den fehler findet.)

[...]
> M

- Thorben