gnokii-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

re: bug #175176, lots of question about nk7110 code


From: Peter Gervai
Subject: re: bug #175176, lots of question about nk7110 code
Date: Mon, 13 Jan 2003 21:09:28 +0100
User-agent: Mutt/1.4i

Hello,

I submitted the bug (i cannot reply to the email since i just subscribed),
and I see that some wanted more info.

I created a debug version, and I'm making myself angry on the code right
now. Seems bounds checking isn't too popular around.

I have some finsings which may help the code, or may prove that i'm
completely stupid and should keep my big mouth shut.

Zeroth fact: I'm using the source from debian, and I'm commaneting on it. If
there is any significant diff between the release code and that please
forgive me. If you want me to test any different version just ask, but
please bear in mind that I already spent too much time on that (I'm short on
time), and uncompilable versions won't help.

First, I wasn't able to compile a debug version because I think:

--- c   2002-08-05 18:21:21.000000000 +0200
 +++ configure   2003-01-13 15:10:41.000000000 +0100
 @@ -1274,7 +1274,7 @@
  fi


 -if test -n "$CFLAGS"; then
 +if test -z "$CFLAGS"; then
         CFLAGS="-O2 -Wall"
  fi

After that at least I can debug. I have a full debug of the problem I
mentioned in the debian bugreport, which can bet retrieved from there:
http://bugs.debian.org/cgi-bin/bugreport.cgi/crash1.log.gz?bug=175176&msg=7&att=0

The path is probably not that impossible after all.

Then I tried to get done what I wanted and read the damned calendar with
xgnokii. It doesnt work. After checking the code, it seems no wonder:

--- n   2002-08-05 18:21:20.000000000 +0200
+++ nk7110.c    2003-01-13 20:13:14.000000000 +0100
@@ -1496,8 +1496,13 @@
                data->CalendarNotesList->Number = (message[4] << 8) + 
message[5];
                dprintf("Location of Notes: ");
                for (i = 0; i < data->CalendarNotesList->Number; i++) {
-                       data->CalendarNotesList->Location[i] = (message[8 + 2 * 
i] << 8) | message[9 + 2 * i];
-                       dprintf("%i ", data->CalendarNotesList->Location[i]);
+                       dprintf("%i (%i)", 
data->CalendarNotesList->Location[i], i);
+                       if( (9 + 2 * i) <= length ) {
+                               data->CalendarNotesList->Location[i] = 
(message[8 + 2 * i] << 8) | message[9 + 2 * i];
+                       } else {
+                               dprintf("ERR!");
+                               data->CalendarNotesList->Location[i] = 0;
+                       }
                }
                dprintf("\n");
                break;

Without understanding the code, seems it wasn't bound checked and 'message[8
+ 2 * i]' was segfaulting because it's not that nice to read the 1100th element
from a 208 length array. (first number varies)

But this just stopping the segfaults, it won't help the calendar code, since:

Message sent: 0x13 / 0x0006
00 01 00 3a ff fe                               |    :
[Received Ack of type 13, seq:  0]
@@ frame=2 seq=70
@@ malloc MessageBuffer (0) ml=0
@@ realloc MessageBuffer (122) ml=0
@@ ml + framelength-2 (120) = 120
[Sending Ack of type 13, seq: 6]
@@ frame=1 seq=7
@@ realloc MessageBuffer (210) ml=120
@@ ml + framelength-2 (88) = 208
[Sending Ack of type 13, seq: 7]
@@ calling sm_incomingfunction with ml=208
Message received: 0x13 / 0x00d0
01 0e 00 3b 02 94 64 00 00 00 00 01 00 02 00 3c |    ;  d        <
00 3d 00 54 00 03 00 04 00 05 00 06 00 69 00 07 |  = T         i
00 08 01 92 00 09 00 f3 00 6f 00 0a 02 be 00 0b |          o
00 0c 00 0d 00 0e 00 0f 00 10 00 11 00 12 00 13 |
00 14 00 15 00 16 00 17 00 18 00 19 00 1a 00 1b |
00 1c 00 1d 00 21 00 20 00 22 00 23 00 24 00 25 |      !   " # $ %
00 26 00 28 00 29 00 2b 00 2e 00 2a 00 2c 00 2f |  & ( ) + . * , /
00 30 00 31 00 33 00 34 00 35 00 38 00 32 00 39 |  0 1 3 4 5 8 2 9
00 3a 00 3b 00 3e 00 3f 00 41 00 40 00 42 00 36 |  : ; > ? A @ B 6
00 37 00 44 00 46 00 43 00 45 00 48 00 49 00 4a |  7 D F C E H I J
00 4c 00 4d 00 4e 00 4f 00 50 00 51 00 52 00 53 |  L M N O P Q R S
00 4b 00 55 00 56 00 57 00 58 00 59 00 5a 00 5b |  K U V W X Y Z [
00 5c 00 5d 00 5f 00 60 00 62 00 61 00 63 00 65
Received message type 13
Year: 1972
Calendar Notes Info received! 660
Location of Notes: 0 (0)1 (1)2 (2)60 (3)61 (4)84 (5)3 (6)4 (7)5 (8)6 (9)105
(10)7 (11)8 (12)402 (13)9 (14)243 (15)111 (16)10 (17)702 (18)11 (19)12
(20)13 (21)14 (22)15 (23)16 (24)17 (25)18 (26)19 (27)20 (28)21 (29)22 (30)23
(31)24 (32)25 (33)26 (34)27 (35)28 (36)29 (37)33 (38)32 (39)34 (40)35 (41)36
(42)37 (43)38 (44)40 (45)41 (46)43 (47)46 (48)42 (49)44 (50)47 (51)48 (52)49
(53)51 (54)52 (55)53 (56)56 (57)50 (58)57 (59)58 (60)59 (61)62 (62)63 (63)65
(64)64 (65)66 (66)54 (67)55 (68)68 (69)70 (70)67 (71)69 (72)72 (73)73 (74)74
(75)76 (76)77 (77)78 (78)79 (79)80 (80)81 (81)82 (82)83 (83)75 (84)85 (85)86
(86)87 (87)88 (88)89 (89)90 (90)91 (91)92 (92)93 (93)95 (94)96 (95)98 (96)97
(97)99 (98)101 (99)0 (100)ERR!0 (101)ERR!0 (102)ERR!0 (103)ERR!0 (104)ERR!0
(105)ERR!0 (106)ERR!0 (107)ERR!0 (108)ERR!0 (109)ERR!0 (110)ERR!0 (111)ERR!0
[...]

(@@ lines are my own debugging of the memory allocation) So as far as I see
(which is not much knowing existence of gnokii for 4 hours already) calendar
would like to send 660 entries and gnokii see 208 bytes in the packet, which
seems to be quite few. I suspsect either the protocol is not well known, or
gnokii handles something terribly lazy, but the largest packet I saw is 208 
bytes (to be honest ALL calendar packets were 208 long), and this means
after I pacthed the segfault gnokii cannot get calendar entry higher than
100 or so.

That I figured out so far. Maybe I see it completely wrong, maybe I helped.
I still have the debug version around, I can do any test people like. I
would like to save the calendar because it's full.... that's my driving
force right now.

thanks,
peter

ps: I TRY to check cvs version, but cvs habitually don't work for me.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]