Bug in GTKTerm 0.99.5

Gast #606510
Lesenswert?

GTKTerm 0.99.5 hat einen Bug eingebaut.

Betrifft den HEXVIEW-Modus!
Problem ist, daß beim einlesen von Bytes alles gut geht bis ein 0x00 
kommt.

In meinem Fall habe ich 0x80 0x00 0x01 0x00 via RS232 gesendet und 
GTKTerm brachte u. a. sowas raus: 0x80 0x00 0xC3 0x11

Schuld ist eine Funktion, die eizelne Bytes von einem Quell- in einen 
Zielstring kopiert, und zwar solange, bis ein 0-Byte (0x00) aufkreuzt. 
Dann ist's vorbei mit kopieren und der Rest ist irgendnen Datenkrams.

Wer dennoch GTKTerm benutzen will ohne diesen Bug, ändert im Quellcode, 
File "src/buffer.c", Zeile 61, von
1
buffer_tmp = g_string_new(chars);
in
1
buffer_tmp = g_string_new_len(chars, size);
um, dann nochmal make drüberrattern lassen (evtl. noch ./configure falls 
noch nicht gemacht) und fertig.

Als Dateianahng so eine abgewandelte Version.

Gruß
 Hegy
Angehängte Dateien:
Gast #616717
Lesenswert?

Und zum Schluß die lauffähige Version. Wer selber den Fehler wegändern 
will, er liegt hier:

Im Archiv File src/widgets.c, Zeile 363 ff. Funktion put_hexadecimal(). 
Bug: Wenn der Cursor im Term-Fenster auf Spalte 0 steht, wird auch die 
Bytezählvariable 'bytes' auf 0 gesetzt, obwohl von der vorangegangenen 
Zeile noch Bytes geschrieben worden sind. Bsp.: In Zeile 1 werden nach 
und nach im 16-Byte-Modus (16 Byte = 1 Zeile) 14 Byte reingeschrieben. 
Jetzt kommt der nächste Datensatz, der aus 5 Bytes besteht. 2 Bytes 
werden in Zeile 1 geschrieben, dann automatisch wird in Zeile 2 der Rest 
reingeschrieben, also 3 Bytes. Die Var. 'bytes' wird dann aber auf 0 
gesetzt und die jetzt nachfolgenden Bytes werden von 0 an gezählt, 
obwohl schon 3 Bytes in der Zeile stehen, daher kommt es zum Versatz von 
3 Bytes in Zeile 2. Sieht dann so aus:

Zeile 1: xx xx xx xx xx xx xx xx - xx xx xx xx xx xx B1 B2
Zeile 2: B3 B4 B5 xx xx xx xx xx xx xx xx - xx xx xx xx xx xx xx xx

Die geänderte Funktion hierzu:
1
void put_hexadecimal(gchar *string, guint size)
2
{                                              
3
  static gchar data[128], data_byte[6];
4
  static guint bytes;                  
5
  glong column, row; 
6
  gint i = 0;       
7
             
8
  if(size == 0)
9
    return;    
10
           
11
  while(i < size)
12
  {              
13
    while(gtk_events_pending()) gtk_main_iteration();
14

15
    vte_terminal_get_cursor_position(VTE_TERMINAL(display), &column, &row);
16

17
    // diesen Teil habe ich umgestellt, da wurde der Fehler deutlich.
18
    // ursrünglich hieß es
19
    // if(show_index)
20
    // {
21
    //     if(column == 0)
22
    //         /* First byte on line */
23
    //  usw.
24
    if(column == 0) /* First byte on line */
25
    {                                       
26
      //bytes = 0; hier war der Hund begraben
27
      if(show_index)
28
      {
29
        sprintf(data, "%6d: ", total_bytes);
30
        vte_terminal_feed(VTE_TERMINAL(display), data, strlen(data));
31
      }                                                              
32
    }  
33
     
34
    /* Print hexadecimal characters */
35
    data[0] = 0;
36

37
    while(i < size) // war: while(bytes < bytes_per_line && i< size)
38
    {
39
      gint avance=0;
40
      gchar ascii[1];
41
      
42
      sprintf(data_byte, "%02X ", (guchar)string[i]);
43
      //printf("%02X ", (guchar)string[i]);
44
      vte_terminal_feed(VTE_TERMINAL(display), data_byte, 3);
45
      
46
      avance = (bytes_per_line - bytes) * 3 + bytes + 2;
47
      
48
      /* Move forward */
49
      sprintf(data_byte, "%c[%dC", 27, avance);
50
      vte_terminal_feed(VTE_TERMINAL(display), data_byte, strlen(data_byte));
51
                                                                             
52
      /* Print ascii characters */                                           
53
      ascii[0] = (string[i] > 0x1F) ? string[i] : '.';
54
      vte_terminal_feed(VTE_TERMINAL(display), ascii, 1);
55
      
56
      /* Move backward */
57
      sprintf(data_byte, "%c[%dD", 27, avance + 1);
58
      vte_terminal_feed(VTE_TERMINAL(display), data_byte, strlen(data_byte));
59
                                                                             
60
      if(bytes == bytes_per_line / 2 - 1)                                    
61
      {
62
        vte_terminal_feed(VTE_TERMINAL(display), "- ", strlen("- "));
63
        //printf("- ");
64
      }
65
      
66
      bytes++;
67
      i++;
68
      
69
      /* End of line ? */
70
      if(bytes == bytes_per_line)
71
      {
72
        vte_terminal_feed(VTE_TERMINAL(display), "\r\n", 2);
73
        total_bytes += bytes;
74
        bytes = 0;
75
        //printf("\n");
76
      }
77
    }
78
  }
79
}

Alerdings bleibt die zusammengestauchte Ansicht bei der 24/32-Byte 
Darstellung, da hilft nur ein gaaaaaanz breites Term-Fenster. Oder 
Mikro-Schrift.
Angehängte Dateien:
Gast #616756
Lesenswert?

Mit der obigen Version ist auch ein Fehler reingekommen.... kommt davon, 
wenn man sein eigenen Krmas nicht selber mal chekkt. Die Index-Nummern, 
die wahlweise eingeschaltet werden können, sind flöten gegangen. Aber 
jetzt sindse wieder da.

Unter
1
vte_terminal_get_cursor_position(VTE_TERMINAL(display), &column, &row);
 diesen Block rein. Die if-Geschichte
1
if(column == 0) /* First byte on line */
wird damit ersetzt oder eben ergänzt.
1
    if(row == 0 && column == 0)
2
    {                          
3
      bytes = 0;
4
      sprintf(data, "%6d: ", total_bytes);
5
      vte_terminal_feed(VTE_TERMINAL(display), data, strlen(data));
6
    }

Oder den Daunlohd machen.

Als näxtes kukkich, wie man da Scrollbalken reinkricht 
(gtk_scrolled_window_new() sollte es sein).
Angehängte Dateien:
Gast #617615
Lesenswert?

Rummaulen kann ich auch! In einem diff steht aber nicht, was da nicht 
richtig tikkt. Kann ja sein, daß meine Vorschläge "suboptimal" sind. 
Außerdem kenn ich mich mit den Tools so gut auch nicht aus, aber ich 
gebe zu, ein diff ist sicherlich sinnvoll, obwohl ja nicht jeder einen 
gcc & Co. auf der Platte hat. Da kommt man evtl. mit einem Binärteil 
schon besser zurecht. Aber egal, hier ist ein diff aus dem 
src/-Verzeichnis. Ich hoffe mal, ich hab das richtig gemacht.
Angehängte Dateien:
Gast #618594
Lesenswert?

Den Urheber habe ich jetzt zum 2. Mal kontaktiert, auch eine andere 
Mail-Adresse, die ich in der Doku gefunden habe, habe ich angeschrieben. 
Bisher leider keine Rückmeldung. Ich nehme im übrigen auch an, daß das 
Projekt eingeschlafen ist, da seit 2005 keine Updates/Bugfixes mehr 
erfolgten.
Gast #628246
Lesenswert?

Gerade eben den Heimatseitenmeister von www.jls-info.com 
(jlsinfo,at,wanadoo.fr) angeschrieben, mit der Bitte um Weiterleitung 
der angehängten Mail (Fehlerbeschreibung der zwei Bugs). Mal kukken, was 
passiert, wenn überhaupt.
Gast #792248
Lesenswert?

Hallo zusammen,

der Bug hat mich gerade nen halben Tag gekostet argh.
Verwende Debian und hab darauf vertraut, dass die Pakete in Ordnung 
sind.

Wenn der Urheber des Programms nicht antwortet, koennte man wenigstens 
die Paket-Maintainer von Debian dazu bringen, den Bug zu beheben? (Oder 
das Paket rausschmeissen ...!)

Kennt jemand das Procedere was man an wen wie schicken soll/darf?

Gruesse

Thorsten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren