Hallo, ich habe lange Zeit nach einem Fehler bei mir gesucht, aber mir gehen langsam die Ideen aus ;-) Ich erweitere gerade den JCapi-Treiber fuer die Nutzung auf 64-Bit-Systemen und fliege auf einem OpenSuSE 10.2 staendig auf die Nase. Wenn ich mir das erzeugte DATA_B3_REQ ausgeben lassen, sieht das folgendermassen aus: -------------> Fri Jun 15 10:35:10 CEST 2007 362 Message ID: 83 -------------------------------------------------------------------------------- Raw length: 30 1e 00 02 00 86 80 83 00 01 02 01 00 00 00 00 00 '????????????????' 13 00 01 00 00 00 40 1c 77 ab aa 2a 00 00 '??????@?wǻ*??' -------------------------------------------------------------------------------- DATA_B3_REQ 2 Data-Handle = 0x1 Data-Length = 0x13 Flags = 00000000000000000000000000000000 NCCI = 0x10201 Data = 0x0 Data64 = 0x2aaaab771c40 Soweit alles OK und an sich "standardkonform". Der JNI-Wrapper macht dann folgendes bevor es an den CAPI-Layer weitergegeben wird: JNIEXPORT jint JNICALL Java_net_sourceforge_jcapi_Jcapi_nPutMessage (JNIEnv *env, jclass, jint appid, jbyteArray ja) { jbyte *msg; jint rc; msg = env->GetByteArrayElements(ja, 0); rc = (jint)(*capi20_put_message)((unsigned int)appid,(unsigned char *)msg); env->ReleaseByteArrayElements(ja, msg, 0); // after call of CapiPutMessage the CAPI works with it's own copy of the message return rc; } Also auch hier keine Magie, die etwas kaputtmachen wuerde (der Datenbereich wurde schon im Vorfeld gepinned, daher ist hier nur der reine Messagebereich betroffen. Versuche ich das ganze, fliegt mir die Java Virtual Machine aber um die Ohren mit folgender Meldung: | # SIGSEGV (0xb) at pc=0x00002b278a2a6812, pid=22309, tid=1120397632 [...] | --------------- T H R E A D --------------- | | Current thread (0x00002aaaab9c0c60): JavaThread "OFTP ReceiveThread(2)" [_thread_in_native, id=22356] | | siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0xffffffffab771c40 [...] | Stack: [0x0000000042b7e000,0x0000000042c7f000), sp=0x0000000042c7cc60, free space=1019k | Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) | C [libc.so.6+0x76812] memcpy+0x52 Anhand der si_addr kann man sehen, dass der urspruenglich 8-Byte-Pointer, wie er durch Data64 uebergeben wurde, wohl an irgendeiner Stelle auf 32 Bit gecastet wurde. Und wie gesagt sehe ich in meinem Code leider nicht, wo das passieren koennte, denn die Traceausgabe von ganz oben passiert direkt vor dem Aufruf der nPutMessage im JNI-Wrapper. Meine Vermutung, warum das knallt, liegt in capi20.c in den capi4k-utils (Zeile 291f): | memcpy(&data64,Msg+22, sizeof(u_int64_t)); | if (data64 != 0) dataptr = (void *)(unsigned long)data64; | else dataptr = Msg + len; /* Assume data after message */ Laut http://www.cygwin.com/ml/libc-hacker/2006-02/msg00060.html gab es wohl mal eine Zeit, als u_int64_t in manchen Bibliotheken 32 Bit breit war bzw. habe ich mal gelernt, das long nicht immer 64 Bit sein muss. In beiden Faellen wuerde man die Haelfte der Pointerinformationen verlieren. Warum das bisher nicht aufgefallen ist, duerfte daran liegen, dass man alternativ den Datenbereich direkt im Anschluss der CAPI-Message haben kann und dann Data und Data64 auf 0 laesst (dritte Zeile im Zitat oben). Es wuerde mich freuen, wenn mir jemand sagen koennte, dass ich mich irre und das Problem trotzdem bei mir liegt, dann gehe ich gerne auch wieder zurueck in eine C-For-Beginners-Newsgroup und sage nichts mehr ;-) Als Fix muesste ich speziell fuer unixoide System den Datenbereich an das Ende des Messagebereichs umkopieren und das wuerde ich eigentlich gerne vermeiden, wenn es nicht unbedingt sein muss. Danke und Gruesse, Lothar --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-isdn-de+help@opensuse.org