Debugger verweigert Breakpoint



  • Ich habe ein eigentlich unverdächtiges Konstrukt:

    switch(selected)
    		{
    			case 'x':
    			{
    				for( i = 0; i < allelements; i++)
    				if(	(fabs(drivetable[i].ax) > acclevel) &&
    					(fabs(drivetable[i].ay) < acclevel) &&
    					(fabs(drivetable[i].az) < acclevel))
    				{
    				printf("%cx- Achse\n", selected);
    					axeelement.trcline = drivetable[i].trcline;
    					axeelement.ptime = drivetable[i].ptime;
    					axeelement.dt = drivetable[i].dt;
    					axeelement.dpos = drivetable[i].dx;
    					axeelement.pos = drivetable[i].px;
    					axeelement.vel = drivetable[i].vx;
    					axeelement.acc = drivetable[i].ax;
    					errors |= MakeAxeList(&axeelement, &axelist, elements);
    				}
    				else 
    					printf("Dataset x- %i dropped!\n", drivetable[i].trcline);
    			}
    				break;
    // ...
    		}
    

    Jetzt kommt der Gimmick: Die printf()- calls sind nur zu Debug- Zwecken drin und werden aber wie erwartet ausgeführtl. Aber einen Breakpoint kann ich nicht drauf setzen, die schmeißt mir der Debugger vor Start raus, da wär kein ausführbarer Code. Aber er führts doch aus! Überseh ich was oder spinnt die IDE?



  • @Sarkast
    Schon mal ein Rebuild gemacht? Nutzt du aktuell auch den Debug Build?



  • @Sarkast sagte in Debugger verweigert Breakpoint:

    Ich habe ein eigentlich unverdächtiges Konstrukt:

    Kurzer Kommentar dazu, der nichts mit deinem Problem zu tun haben wird: subtile Bugs sind immer in dem Codeabschnitt, den man für unverdächtig hält. 😉

    Ansonsten noch: ich würde versuchen zu vermeiden, längeren Code innerhalb von "case"-Bereichen zu schreiben. Meiner Meinung nach sollte man das gesamte switch auf einmal sehen können. Bei so viel Code kannst du ein fehlendes break leicht übersehen oder ggf. die Fälle nicht gut überblicken. Ich würde daher vorschlagen, dass du den case-Code in eine Funktion auslagerst. Ja, ich weiß, dass das bei vielen Variablen nerven kann. Aber dann hat der ganze Abschnitt wenigstens automatisch einen Namen.



  • @Quiche-Lorraine sagte in Debugger verweigert Breakpoint:

    @Sarkast
    Schon mal ein Rebuild gemacht? Nutzt du aktuell auch den Debug Build?

    Beides korrekt. Debug- Version sicher und rebuild probiert.



  • Welche IDE verwendest du?

    Falls Visual Studio:
    Auf älteren Visual Studio Versionen hatte ich manchmal ähnliche Fälle wo es geholfen hat alle Breakpoints zu löschen (mit dem "alle Breakpoints löschen" Kommando, nicht einzeln!), und sie dann neu zu setzen.
    Du kannst auch auch probieren die "*.user" Files zu löschen.



  • @wob sagte in Debugger verweigert Breakpoint:

    @Sarkast sagte in Debugger verweigert Breakpoint:

    Ich habe ein eigentlich unverdächtiges Konstrukt:

    Kurzer Kommentar dazu, der nichts mit deinem Problem zu tun haben wird: subtile Bugs sind immer in dem Codeabschnitt, den man für unverdächtig hält. 😉

    Ansonsten noch: ich würde versuchen zu vermeiden, längeren Code innerhalb von "case"-Bereichen zu schreiben. Meiner Meinung nach sollte man das gesamte switch auf einmal sehen können. ...

    Viel rauskürzen kann ich da nicht mehr. Sonst hätte ich das if()- Gedöns in der aufgerufenen Funktion.

    @hustbaer sagte in Debugger verweigert Breakpoint:

    Welche IDE verwendest du?

    Pelles C. Mit dem aktuellen VS würde der Rechner unbedienbar. Aber ich hab mal alle Breakpoints auf einen Zack gelöscht und neu gesetzt. Kein Unterschied.



  • @Quiche-Lorraine
    @hustbaer
    Jetzt habe ich das Projekt nach Code::Blocks übernommen und stehe vor de3m Problem, daß ich jetzt zwar Breakpoints setzen kann, aber der code nicht mehr läuft.

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include "structs.h"
    int ParseEckelLine (char *buffer, eckelset *eckelline)
    {
    	char *partstring1;
    	char *partstring2;
    	eckelline->missing = 0;
    	printf("%s\n", buffer);
    // gibt "t10i git779585 X1010.28 Y98.3167 Z-93.4155 C7668.3 x2370.8 y761.379" aus
    	partstring1 = strstr(buffer, "t10i");
    	if(!partstring1)
    		return -1; // Ist immer NULL
    // ...
    

    Jetzt geht strstr nicht - es ist zum Heulen. Oder mach ich was falsch?



  • @Sarkast
    Merkwürdig

    Probiere doch mal bitte folgendes aus. Setze ein neues Projekt in Code::Blocks auf, kopiere den folgenden Code und prüfe was dabei herauskommt. Ich möchte sicherstellen das da kein Codierungsproblem vorhanden ist. Gerade das Zeichen i aus dem Suchstring t10i hat einige ähnliche aussehende Verwandten.

    #include <stdi o.h>
    #include <stdlib.h>
    #include <string.h>
    
    int main() 
    {
        char const* const buffer = "t10i git779585 X1010.28 Y98.3167 Z-93.4155 C7668.3 x2370.8 y761.379";
        char *partstring1;
        
        printf("%s\n", buffer);
        partstring1 = strstr(buffer, "t10i");
        if(!partstring1)
          printf("Pattern not found\n");
        else
          printf("Pattern found\n");    
    }
    


  • @Quiche-Lorraine sagte in Debugger verweigert Breakpoint:

    #include <stdi o.h>
    #include <stdlib.h>
    #include <string.h>

    int main()
    {
    char const* const buffer = "t10i git779585 X1010.28 Y98.3167 Z-93.4155 C7668.3 x2370.8 y761.379";
    char *partstring1;

    printf("%s\n", buffer);
    partstring1 = strstr(buffer, "t10i");
    if(!partstring1)
      printf("Pattern not found\n");
    else
      printf("Pattern found\n");    
    

    }

    OK, console Output:

    ```plain
    t10i git779585 X1010.28 Y98.3167 Z-93.4155 C7668.3 x2370.8 y761.379
    Pattern found
    
    Process returned 0 (0x0)   execution time : 0.147 s
    Press any key to continue.
    

    Ab jetzt versteh ich gar nicht mehr, was sich tut.



  • Naja setz halt den Breakpoint auf die strstr Zeile und guck nach was wirklich in buffer drin steht - da kannst du dir dann auch einfach die numerischen Werte der einzelnen Character ansehen. Notfalls kannst du auch nach strstr reinsteppen. Das sollte jetzt wirklich kein unlösbares Problem sein.



  • @hustbaer Ich häng jetz an so einem Kram fest. Ich komme über eigenimplementierten Kram schneller weiter. Ne search auf char[] funktioniert.



  • @Sarkast

    Probiere doch mal bitte die folgende strstr Implementierung aus. Diese gibt die Eingaben von strstr hexadezimal aus. Prüfe mal ob dein Suchstring t10i hexadezimal [74][31][30][69] ist.

    Es könnte nämlich sein dass dein Suchstring kein t10i sondern ein t10ì oder t10í oder t10î oder t10ï ist.

    char* my_strstr(const char* str, const char* substr)
    {
        char const* s;
        
        printf("------------------------------\n");
        s = str;
        while (*s != 0)
        {
            printf("[%X]", *s);
            s++;
        }
        printf("\n");
        printf("------------------------------\n");
        s = substr;
        while (*s != 0)
        {
            printf("[%X]", *s);
            s++;
        }
        printf("\n");
        
        return strstr(str, substr);
    }
    


  • @Quiche-Lorraine Hupps, war mit ein paar anderen Dingen beschäftigt. Ich habs jetztmal selbst gemacht, geht auch. Einziger Unterschied: Das Ergebnis wird aufs Ende des Pattern hits gesetzt. Ist sogar praktischer. "t10i" ist wirklich ein "t10i"
    Immerhin, das tut erstmal:

    char *searchstring(char *haufen, char *nadel, int maxdeep)
    {
        int i,j, l_nadel, l_haufen;
        l_nadel = strnlen(nadel, maxdeep);
        l_haufen = strnlen(haufen, maxdeep);
        maxdeep = l_haufen - l_nadel;
        for(i = 0; (i <= maxdeep) && haufen[i] ; i++)
            for(j=0; (j < l_nadel); j++)
                if(nadel[j] != haufen[i + j])
                    break;
                else
                    if(j == (l_nadel - 1))
                        return &haufen[i + j + 1];
        return NULL;
    }
    


  • @Quiche-Lorraine So, hab jetzt mal deinen code durchlaufen lassen:

    git779585 X1010.28 Y98.3167 Z-93.4155 C7668.3 x2370.8 y761.379
    
    ------------------------------
    [74][31][30][69]
    ------------------------------
    [74][31][30][69][20][67][69][74][37][37][39][35][38][35][20][58][31][30][31][30][2E][32][38][20][59][39][38][2E][33][31][36][37][20][5A][2D][39][33][2E][34][31][35][35][20][43][37][36][36][38][2E][33][20][78][32][33][37][30][2E][38][20][79][37][36][31][2E][33][37][39][A]
    

    Hier die calls:

    char *partstring1;
    	char *partstring2;
    	eckelline->missing = 0;
    //	printf("%s\n", buffer);
    //	partstring1 = strstr(buffer, "t10i");
    	partstring1 = searchstring(buffer, "t10i", 250);
        printf("%s\n", partstring1);
        partstring1 = my_strstr(buffer, "t10i");
        printf("%s\n", partstring1);
    
    //	if(partstring2)
    //	printf("%s\n", partstring2);
    	if(!partstring1)
    		return -1;
    

    Und weil partstring1 als NULL zurückgeliefert wird, wird auch nichts mehr ausgegeben und die Funktion mit -1 verlassen. Ist doch seltsam, was? strstr funktioniert wirklich nicht.



  • @Sarkast
    OK, ein Kodierungsproblem ist es offenbar nicht. Dafür finde ich die folgende Ausgabe merkwürdig:

    git779585 X1010.28 Y98.3167 Z-93.4155 C7668.3 x2370.8 y761.379
    
    ------------------------------
    [74][31][30][69]
    ------------------------------
    [74][31][30][69][20][67][69][74][37][37]...
    

    Folgende Sachen fallen auf:

    • Die erste Zeile ist "git779585..." solle aber "t10i git779585..." sein.
    • Meine my_strstr Funktion gibt zuerst den String aus, in welchem gesucht wird und danach den zu suchenden Teilstring. DIe Ausgabe ist aber verdreht.

    Führe ich den Testcode aus, so erhalte ich folgende Ausgabe:

    t10i git779585 X1010.28 Y98.3167 Z-93.4155 C7668.3 x2370.8 y761.379
    ------------------------------
    [74][31][30][69][20][67][69][74][37][37][39][35][38][35][20][58][31][30][31][30][2E][32][38][20][59][39][38][2E][33][31][36][37][20][5A][2D][39][33][2E][34][31][35][35][20][43][37][36][36][38][2E][33][20][78][32][33][37][30][2E][38][20][79][37][36][31][2E][33][37][39]
    ------------------------------
    [74][31][30][69]
    

    Als wären die Parameter verdreht. Versuch dich da mal reinzudebuggen.



  • @Quiche-Lorraine sagte in Debugger verweigert Breakpoint:

    olgende Sachen fallen auf:

    Die erste Zeile ist "git779585..." solle aber "t10i git779585..." sein.
    Meine my_strstr Funktion gibt zuerst den String aus, in welchem gesucht wird und danach den zu suchenden Teilstring. DIe Ausgabe ist aber verdreht.

    Ja, ich habe den Header tatsächlich verdreht und dann konsequenterweise das Compiler- Gemotze falsch korrigiert So kann's auch nicht funktionieren.
    Und das mit der Zeile ohne "t10i" ist schon gewollt. Ich gebe nur den Substring- Punkt zurück, an dem der Vergleich positiv ist. t10i ist die Trace- Kennung, git bereits Protokolldatum. Die Kennung "git" müßte aber wieder für den sscanf() ausmaskiert werden. Da aber die Reihenfolge strikt ist und nur einzelne Parameter fehlen können und stattdessen andere auftauchen. Also schneid ich das t10i weg und arbeite nur mit dem Reststring weiter. Nachher bei git,
    Also, was vorher war, ich weiß es nicht. Jedenfalls nach Umstieg auf Code::Blocks ging die Breakpoints setzen, hat mir aber keine t10i- Zeile mehr geparst.
    Weiß der Geier, was da war. Zeichencodierung war jedenfalls gute Idee.

    Jedenfalls herzlichen Dank an alle!


Anmelden zum Antworten