Bug in GTKTerm 0.99.5

[Hegy (Gast)]

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

buffer_tmp = g_string_new(chars);

in

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

[Hegy (Gast)]

Noch ein Nachtrag zum vorangegangenem Posting und der angefüchten Datei. 
Defaultmäßig habe ich da den Hex-View Modus eingestellt statt 
ASCII-View. Läßt sich aber nach wie vor umschalten.

[Hegy (Gast)]

Heute war richtiges Scheißwetter, also mal GtkTerm weiter
"entschrottet".
Ein Bug ist z.B. noch der, daß beim Hex-View die Werte durcheinander
dargestellt werden (s. Anhang). Weiter unten dann noch eine
funktionsfähige Variante.

[Hegy (Gast)]

Hier jetzt mal die neue Variante. Ich habe auch gegengecheckt, ob alle 
Bytes auch dargestellt werden und nicht überschrieben werden. Da habe 
ich auf die schnelle nichts festgestellt, dennoch, ohne Garantie.

[Hegy (Gast)]

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:

void put_hexadecimal(gchar *string, guint size)
{                                              
  static gchar data[128], data_byte[6];
  static guint bytes;                  
  glong column, row; 
  gint i = 0;       
             
  if(size == 0)
    return;    
           
  while(i < size)
  {              
    while(gtk_events_pending()) gtk_main_iteration();

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

    // diesen Teil habe ich umgestellt, da wurde der Fehler deutlich.
    // ursrünglich hieß es
    // if(show_index)
    // {
    //     if(column == 0)
    //         /* First byte on line */
    //  usw.
    if(column == 0) /* First byte on line */
    {                                       
      //bytes = 0; hier war der Hund begraben
      if(show_index)
      {
        sprintf(data, "%6d: ", total_bytes);
        vte_terminal_feed(VTE_TERMINAL(display), data, strlen(data));
      }                                                              
    }  
     
    /* Print hexadecimal characters */
    data[0] = 0;

    while(i < size) // war: while(bytes < bytes_per_line && i< size)
    {
      gint avance=0;
      gchar ascii[1];
      
      sprintf(data_byte, "%02X ", (guchar)string[i]);
      //printf("%02X ", (guchar)string[i]);
      vte_terminal_feed(VTE_TERMINAL(display), data_byte, 3);
      
      avance = (bytes_per_line - bytes) * 3 + bytes + 2;
      
      /* Move forward */
      sprintf(data_byte, "%c[%dC", 27, avance);
      vte_terminal_feed(VTE_TERMINAL(display), data_byte, strlen(data_byte));
                                                                             
      /* Print ascii characters */                                           
      ascii[0] = (string[i] > 0x1F) ? string[i] : '.';
      vte_terminal_feed(VTE_TERMINAL(display), ascii, 1);
      
      /* Move backward */
      sprintf(data_byte, "%c[%dD", 27, avance + 1);
      vte_terminal_feed(VTE_TERMINAL(display), data_byte, strlen(data_byte));
                                                                             
      if(bytes == bytes_per_line / 2 - 1)                                    
      {
        vte_terminal_feed(VTE_TERMINAL(display), "- ", strlen("- "));
        //printf("- ");
      }
      
      bytes++;
      i++;
      
      /* End of line ? */
      if(bytes == bytes_per_line)
      {
        vte_terminal_feed(VTE_TERMINAL(display), "\r\n", 2);
        total_bytes += bytes;
        bytes = 0;
        //printf("\n");
      }
    }
  }
}

Alerdings bleibt die zusammengestauchte Ansicht bei der 24/32-Byte 
Darstellung, da hilft nur ein gaaaaaanz breites Term-Fenster. Oder 
Mikro-Schrift.

[Hegy (Gast)]

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

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

 diesen Block rein. Die if-Geschichte

if(column == 0) /* First byte on line */

wird damit ersetzt oder eben ergänzt.

    if(row == 0 && column == 0)
    {                          
      bytes = 0;
      sprintf(data, "%6d: ", total_bytes);
      vte_terminal_feed(VTE_TERMINAL(display), data, strlen(data));
    }

Oder den Daunlohd machen.

Als näxtes kukkich, wie man da Scrollbalken reinkricht 
(gtk_scrolled_window_new() sollte es sein).

[Rolf Magnus (Gast)]

Statt ellenlangen Beschreibungen, was man alles ändern muß, wäre ein 
diff sinnvoller.

[Hegy (Gast)]

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.

[trikarbonsäureacetat (Gast)]

Was ist denn ein diff?

[Hans (Gast)]

man diff
man patch

auf ner shell oder google fragen

[Andreas S. (andreas) (Admin)]

Wäre es nicht sinnvoller den Patch gleich an den Urheber des Programms 
zu schicken?

[Hegy (Gast)]

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.

[Hegy (Gast)]

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.

[Thorsten (Gast)]

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