[vz-dev] vzlogger 0.3.3 stürzt nach 5 - 10 min ab

Thorben Thuermer r00t at constancy.org
Fri Mar 30 22:13:22 CEST 2012


Hallo nochmal,

ich deke ich habe das problem schon...

in libsml/src/sml_status.c:sml_status_parse() findet sich folgendes:
 29 sml_status *sml_status_parse(sml_buffer *buf) {
 38         sml_status *status = (sml_status *) malloc(sizeof(sml_status));
 40         switch (type) {
 41                 case SML_TYPE_UNSIGNED:
 47                         status->data.status8 = sml_number_parse(buf, type, max);
 49                         break;
 50                 default:
 51                         buf->error = 1;
 52                         break;
 53         }
 54         if (sml_buf_has_errors(buf)) {
 55                 sml_status_free(status);
 56                 return 0;
 57         }
 59         return status;

falls hier der "case SML_TYPE_UNSIGNED" NICHT eintritt, wird status->data
nie beschrieben, aber durch die buf->error-logik wird status_free auf
status aufgerufen, wo status->data free'd wird.
also einfach ein fehler in fehlerbehandlung.

als fix wuerde sich zB folgendes anbieten:
diff --git a/sml/src/sml_status.c b/sml/src/sml_status.c
index 1b486f6..bc15bb6 100644
--- a/sml/src/sml_status.c
+++ b/sml/src/sml_status.c
@@ -37,6 +37,7 @@ sml_status *sml_status_parse(sml_buffer *buf) {
 
        sml_status *status = (sml_status *) malloc(sizeof(sml_status));
        status->type = type;
+       status->data.status8 = NULL;
        switch (type) {
                case SML_TYPE_UNSIGNED:
                        // get maximal size, if not all bytes are used (example: only 6 bytes for a u64)

dann halt libsml (und vzlogger, falls statisch gelinkt) neukompilieren,
und dann testen bitte :)

- Thorben

On Fri, 30 Mar 2012 21:41:48 +0200 Thorben Thuermer <r00t at constancy.org> wrote:
> Hallo,
> 
> sehr gut!
> hast du vlt. noch das core-file dazu zum weiteren debuggen?
> (sonst naechstesmal eins speichern, in gdb "generate-core-file")
> 
> auf jeden fall koennen wir jetzt sehen:
> der sml-parser hat ein problem beim parsen einer nachricht(?)
> und uebergibt 0xa ('\n'?) an free(), was kein sinnvoller pointer,
> und erst recht nicht mit malloc() alloziert ist, und deswegen
> zu einem abstuerz fuehrt.
> ich werde mir dann den code an den stellen mal anschauen, vlt. ist da schon
> zu erkennen wie es dazu kommen kann - falls steffen nicht schneller ist. ;)
> 
> - Thorben
> 
> On Fri, 30 Mar 2012 15:32:40 +0200
> Wilhelm Eßt <wilhelm.esst at tsv-gersthofen.de> wrote:
> > So ich weiß nicht so recht warum, aber jetzt hat der bt full was geliefert:
> [...]
> > Im Kdevelop war es nun möglich den bt full auszuführen; hier das Ergebnis:
> > 
> > (gdb) bt full
> > bt full
> > #0 *__GI___libc_free (mem=0xa) at malloc.c:3709
> > ar_ptr = <optimized out>
> > p = 0x2
> > #1 0x0805543c in sml_number_free (np=0xa) at src/sml_number.c:120
> > No locals.
> > #2 0x08055fc1 in sml_status_free (status=0x807eeb8) at src/sml_status.c:73
> > No locals.
> > #3 0x08055f25 in sml_status_parse (buf=0x806cb68) at src/sml_status.c:55
> > max = 1
> > type = 16
> > byte = 27 '\033'
> > status = 0x807eeb8
> > #4 0x080559b2 in sml_list_entry_parse (buf=0x806cb68) at src/sml_list.c:124
> > l = 0x807ee40
> > #5 0x08055b61 in sml_list_parse (buf=0x806cb68) at src/sml_list.c:175
> > first = 0x8080a38
> > last = 0x807eee8
> > elems = 4
> > #6 0x08052add in sml_get_list_response_parse (buf=0x806cb68) at 
> > src/sml_get_list_response.c:54
> > msg = 0x807feb0
> > #7 0x080514bd in sml_message_body_parse (buf=0x806cb68) at 
> > src/sml_message.c:165
> > msg_body = 0x807f2f0
> > #8 0x08050fb2 in sml_message_parse (buf=0x806cb68) at src/sml_message.c:56
> > msg = 0x807f1c8
> > #9 0x080502d7 in sml_file_parse (buffer=0xb67aa1b8 "v\a", buffer_len=460) at 
> > src/sml_file.c:50
> > file = 0x806d358
> > buf = 0x806cb68
> > msg = 0x807f1e0
> > #10 0x0804f8d2 in meter_read_sml (meter=0x806c7e0, rds=0x806d548, n=32) at 
> > protocols/sml.c:163
> > handle = 0x806c7f0
> > buffer = 
> > "\033\033\033\033\001\001\001\001v\a\000\r\000\314ksb\000b\000rc\001\001v\001\001\a\000\r\000a#\321\v\006EMH\001\002q\\\022\270\001\001c\376\032\000v\a\000\r\000\314ktb\000b\000rc\a\001w\001\v\006EMH\001\002q\\\022\270\001rb\001e\000aB\tww\a\201\201�\202\003\377\001\001\001\001\004EMH\001w\a\001\000\000\000\t\377\001\001\001\001\v\006EMH\001\002q\\\022\270\001w\a\001\000\001\b\000\377c\001\202\001b\036R\377V\000\000#\020\305\001w\a\001\000\001\b\033\033\033\033\001\001\001\001v\a\000\r\000\314kyb\000b\000rc\001\001v\001\001\a\000\r\000a#\323\v\006EMH\001\002q\\\022\270\001\001cͪ\000v\a\000\r\000\314kzb\000"...
> [...]
> > Wilhelm Eßt


More information about the volkszaehler-dev mailing list