Moin.

Weil ich mit dem debug output so gar nichts anfangen kann, habe ich
mal angefangen den code anzugucken und ein wenig mit gdb zu
spionieren, was der code denn so treibt.

(Ich hoffe dann im nächsten Jahr vielleicht mal auf konkrete Hinweise,
welche Info denn wirklich benötigt wird, um dem Problem auf die
Schliche zu kommen. Sonst muss ich nämlich raten, was nun gebraucht
wird.)

Dabei ist mir ein kleine Meldung aufgefallen

Syscall param socketcall.bind(my_addr..sun_path) points to
unaddressable byte(s)

Die hatte ich erst in Verdacht, etwas mit den timeouts auf dem socket
und den buffer overruns zu tun zu haben, aber nachdem ich die
betreffende Stelle in GWEN_InetAddr_dup etwas aufgeräumt habe, ist
valgrind ruhig (bis auf diverse angebliche (!) Speicherlecks, aber
denen nachzugehen erfordert Erfahrungsgemäß deutlich bessere Kenntnis
des Codes), aber mein Problem besteht weiterhin.

Trotzdem schicke ich mal den Patch, falls er nützlich sein sollte.

diff --git a/gwenhywfar-3.6.0/src/os/posix/inetaddr.c 
b/gwenhywfar-3.6.0/src/os/posix/in
index c0988a0..effd720 100644
--- a/gwenhywfar-3.6.0/src/os/posix/inetaddr.c
+++ b/gwenhywfar-3.6.0/src/os/posix/inetaddr.c
@@ -138,12 +138,21 @@ GWEN_INETADDRESS *GWEN_InetAddr_dup(const 
GWEN_INETADDRESS *oa){
   GWEN_NEW_OBJECT(GWEN_INETADDRESS, ia);
   ia->af=oa->af;
   ia->size=oa->size;
-  //ia->address=(struct sockaddr *)malloc(sizeof(struct sockaddr));
-  if (oa->size) {
-    ia->address=(struct sockaddr *)malloc(oa->size);
-    assert(ia->address);
-    memmove(ia->address, oa->address, oa->size);
+  size_t size = 0;
+  switch (ia->af) {
+  case GWEN_AddressFamilyUnix:
+    size = sizeof(struct sockaddr_un);
+    break;
+  case GWEN_AddressFamilyIP:
+    size = sizeof(struct sockaddr_in);
+    break;
+  default:
+    DBG_INFO(GWEN_LOGDOMAIN, "Unknown address family (%d)",ia->af);
+    assert(0);
   }
+  ia->address=(struct sockaddr *)malloc(size);
+  assert(ia->address);
+  memmove(ia->address, oa->address, size);
   return ia;
 }

Ist wohl Geschmacksache. Vorher wurden halt nur so viele Bytes
alloziert, wie tatsächlich gebraucht wurden, was vermutlich ok ist, so
lange nicht irgendeine Library vielleicht doch mal das komplette
struct (110 bytes) kopieren will oder ähnliches.


-- 
        Friedrich Delgado Friedrichs <frie...@nomaden.org>
Laziness led to the invention of the most useful tools.

Attachment: pgpArjQ4ReoVM.pgp
Description: PGP signature

------------------------------------------------------------------------------
_______________________________________________
Aqbanking-devel mailing list
Aqbanking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aqbanking-devel

Reply via email to