mikrocontroller.net

Forum: PC Hard- und Software Bug in GTKTerm 0.99.5


Autor: Hegy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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
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

Autor: Hegy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hegy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hegy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hegy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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:
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.

Autor: Hegy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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
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).

Autor: Rolf Magnus (Gast)
Datum:

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

Autor: Hegy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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.

Autor: trikarbonsäureacetat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist denn ein diff?

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
man diff
man patch

auf ner shell oder google fragen

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: Hegy (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hegy (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.