NULL Pointer als Übergabe in Funktion verursacht sporadische Fehler

der code ist nicht gerade gut zu lesen, viel zu verschachtelt.

im ersten Moment kann ich aber keinen Fehler finden, kann es sein das es 
in  PS_ProgrammeUebernehmen() zu einen Fehler kommt.

Rufus Τ. F. schrieb:
> Ralf schrieb:
>> Es liegt an der Übergabe des NULL-Zeigers, aber warum?
>
> Kann nicht sein. Die Funktion wertet ihren zweiten Parameter nirgends
> aus.

Leider doch. An zwei Stellen. Aber ich musste auch erst suchen.

Robin R. schrieb:
> Das selbe passiert mit "id" und "Param", werden gelesen, obwohl sie ggf.
> NULL sind.

Nö werden sie von dem Funktionsaufruf nicht. Wie willst du einen Pointer 
denn auf Länge prüfen?

Rufus Τ. F. schrieb:
> Kann nicht sein. Die Funktion wertet ihren zweiten Parameter nirgends
> aus.

Eben aber wenn ich den Funktionsaufruf noppe funktioniert alles Stabil.
Nur dieser Aufruf verursacht den Fehler nach einigen Aufrufen.

Peter II schrieb:
> im ersten Moment kann ich aber keinen Fehler finden, kann es sein das es
> in  PS_ProgrammeUebernehmen() zu einen Fehler kommt.

Passiert nichts dolles:

1

void PS_ProgrammeUebernehmen(void)

2

{

3

  // Übernimmt das aktivierte Programm mit der höchsten Priorität:

4

  bool KeinProgrammGefunden = 1;

5

6

  // Prüfe auf Umschalten - Grundprogramm wird ignoriert:

7

  for(uint8_t a = 1; a < SYS_AnzahlZustaende; a++)

8

  {

9

    if(InfoTable[a].Aktiviert)

10

    {

11

      if(LS_AktuellesProgramm != a)

12

      {

13

        LS_AktuellesProgramm = a;

14

        LS_ProgrammNeuLaden = 1;

15

      }

16

17

      KeinProgrammGefunden = 0;

18

      break;

19

    }

20

  }

21

22

  // Wenn es keine aktivierten Programme gibt, schalte in das 0. Programm!

23

  if(KeinProgrammGefunden && LS_AktuellesProgramm != 0)

24

  {

25

    LS_AktuellesProgramm = 0;

26

    LS_ProgrammNeuLaden = 1;

27

  }

28

}

Robin R. schrieb:
> Du setzt nirgends PROG_UNDEFINIERT.

Doch:

1

typedef enum{

2

  EVENT_EINGEHENDER_ANRUF,

3

  EVENT_EINGEHENDER_ANRUF_BEENDET,

4

5

  EVENT_VERPASSTER_ANRUF,

6

  EVENT_VERPASSTER_ANRUF_GELESEN,

7

8

  EVENT_VERPASSTE_PUSHNACHRICHT,

9

  EVENT_PUSHNACHRICHT_GELESEN,

10

11

  EVENT_BLE_VERBUNDEN,

12

  EVENT_BLE_GETRENNT,

13

14

  // Blending Programme (Übergangsprogramme):

15

  EVENT_PUSHNACHRICHT,

16

} Event_Typ;

@ Ralf

Andere hier reagieren vielleicht anders und mehr, wie Du es wünschst, 
aber ich muss leider sagen, dass ich mir diesen Code nicht antue.

Dafür gibt es abstrakte Gründe, die Dir vielleicht nützlich erscheinen, 
vielleicht aber auch nicht:

Zum einen hast Du sehr viel Code in eine Funktion geklemmt. Das ist 
nicht eigentlich falsch, führt aber dazu, dass sie nur mit hohem Aufwand 
zu testen ist. Ich rate Dir, die Funktion in mehrere kleinere 
aufzuteilen. Eine bewährte Daumenregel lautet: "Eine Aufgabe, eine 
Funktion" und eine weitere, ebenso bewährte: "Eine Funktion, eine 
Bildschirmseite" (also etwa 25 Zeilen à 80 Zeichen).

Zum anderen ist die Fehlerbeschreibung bzw. die Analyse zu 
oberflächlich.
Es fängt damit an, dass eine NULL als Parameter an sich niemals einen 
Fehler hervorruft, wenn man voraussetzt, dass als Parameter an sich ein 
Zeiger zulässig ist. Das wusstest Du vielleicht nicht.
Aber wenn man das voraussetzt, dann ruft eine NULL effektiv einen Fehler 
bei ihrer Verwendung in einem Ausdruck einen Fehler hervor. Die Stelle 
an der das geschieht musst Du finden und mit einer Wahrscheinlichkeit 
ist auch ziemlich offensichtlich, was da genau schiefläuft - leider 
nicht immer, oft eben auch nicht.

Also bitte überarbeite Deinen Code. Überlege Dir Tests für die 
Einzelfunktion und baue die dann in die Funktion PS_ProgrammEvent ein.

Ralf schrieb:
> Rufus Τ. F. schrieb:
>> Kann nicht sein. Die Funktion wertet ihren zweiten Parameter nirgends
>> aus.
>
> Eben ...

Das sehe ich anders:

In dieser Zeile:

1

if(!LenByte || LenByte <= PS_ProgrammInfoParaLaenge && len == LenByte && !memcmp(&InfoTable[a].Param[1], Param, LenByte))

und in dieser Zeile

1

if(!LenByte || LenByte <= (PS_ProgrammInfoParaLaenge - 1) && len == LenByte && !memcmp(&InfoTable[a].Param[1], Param, LenByte))

wird Param verwendet.

Ralf schrieb:
> Du setzt nirgends PROG_UNDEFINIERT.

Sry. Meinte das hier:

1

typedef enum{

2

  // Stabile Programme (Hauptprogramme)

3

  PROG_UNDEFINIERT = 0,                            // Undefiniertes Programm

4

  PROG_VERPASSTER_ANRUF = 1,                          // Nicht angenommener Anruf

5

  PROG_VERPASSTE_NACHRICHT = 2,                        // Ungelesene Nachricht

6

  PROG_EINGEHENDER_ANRUF = 3,                          // Eingehender Anruf

7

  PROG_BLE_CONNECTED = 4,                            // iPhone per Bluetooth verbunden

8

  PROG_BLE_DISCONNECTED = 5,

9

10

  // Blending Programme (Übergangsprogramme)

11

  PROG_EINGEHENDE_NACHRICHT = 254,

12

} Programm_Typ;

Theor schrieb:
> wird Param verwendet.

Ja aber nicht bei dem konkreten Aufruf.

Eine zweifach verschachtelte Schleife mit einer mehrdimensionalen 
Statemachine in der inneren Schleife? WTF? Soll das später noch 
irgendwer anderes warten, oder ist das bloß Wegwerfcode zum privaten 
Eigengebrauch?

Nop schrieb:
> Eine zweifach verschachtelte Schleife mit einer mehrdimensionalen
> Statemachine in der inneren Schleife? WTF? Soll das später noch
> irgendwer anderes warten, oder ist das bloß Wegwerfcode zum privaten
> Eigengebrauch?

Nö, für die Tonne.

Ralf schrieb:
> Theor schrieb:
>> wird Param verwendet.
>
> Ja aber nicht bei dem konkreten Aufruf.

Richtig. Wenn Du den oben zitierten Aufruf machst, dann nicht.
Dann wird aber auch nichts weiter in der ganzen Funktion getan, als

1

InfoTable[a].Aktiviert = 1;

was in der später geposteten Funktion PS_ProgrammeUebernehmen zunächst 
zu nichts weiter als setzen von zur Compile-Zeit definierten Variablen 
bewirkt.

Darin liegt der Fehler jedenfalls nicht.


Ich verweise nochmal auf meinen Beitrag hier: 
Beitrag "Re: NULL Pointer als Übergabe in Funktion verursacht sporadische Fehler"

Dachte das wäre zu unhöflich, aber ich möchte Peter zustimmen: Sehr 
wuselig das Ganze.

Peter D. schrieb:
> Du hast also einen Bytepointer *Param und eine Struct mit einem Member
> .Param.
> Ist zwar erlaubt, sollte man aber nicht tun, da es sehr verwirrend ist.
> Nimm für verschiedene Sachen auch verschiedene Namen.

Guter Anreiz, werde ich ändern!

Peter D. schrieb:
> Das ganze sieht wahnsinnig verworren aus, erweckt aber den Eindruck, daß
> man es viel einfacher und klarer schreiben könnte.

Ist es auch, ist eben eine Abarbeitung von Zuständen. Wenn ich in der 
switch alles in Funktionen Packe, trägt das der Übersichtlichkeit bei, 
das stimmt schon, mache ich ggf. auch.

Grade probiert:

1

PS_ProgrammEvent2(EVENT_PUSHNACHRICHT, NULL, 0, NULL);

1

void PS_ProgrammEvent2(Event_Typ Event, uint8_t *Param, uint16_t len, uint8_t *id)

2

{

3

4

}

[c]void PS_ProgrammEvent2(Event_Typ Event, uint8_t *Param, uint16_t len, 
uint8_t *id);[c]

Verursacht ähnliche Probleme.

Ralf schrieb:
> Grade probiert:
>
>

1

PS_ProgrammEvent2(EVENT_PUSHNACHRICHT, NULL, 0, NULL);

>
>

1

void PS_ProgrammEvent2(Event_Typ Event, uint8_t *Param, uint16_t len, 

2

> uint8_t *id)

3

> {

4

> 

5

> }

>
> [c]void PS_ProgrammEvent2(Event_Typ Event, uint8_t *Param, uint16_t len,
> uint8_t *id);[c]
>
> Verursacht ähnliche Probleme.

Schön. Aber was sollen wir nun damit anfangen?
Du musst das Problem erstmal genau feststellen, beschreiben worin es 
besteht. Ich wiederhole: Eine Null als Parameter verursacht an sich 
keinen Fehler.

Ich glaub, ich gehe ins Bett und lese Don Quichotte. Das passt genau zum 
Thread. :-)

Und ich nehm an meine vielfältigen Bemerkungen werden nicht verstanden?
Schreib ich überhaupt Deutsch? Oder schlaf ich schon?

A. K. schrieb:
> Sollte das
>   memset(&Prog[0], 0, sizeof(Prog[0]));
> nicht eher
>   memset(Prog, 0, sizeof(Prog));
> sein?

Erster produktiver Beitrag, habe ich grade auch bemerkt.
Genau dadurch entstand der Fehler !

Danke

A. K. schrieb:
> memset(&Prog[0], 0, sizeof(Prog[0]));

memset(&Prog[0], 0, sizeof(Prog));

Ralf schrieb:
> memset(&Prog[0], 0, sizeof(Prog));

oder einfach gleich auf 0 setzen

1

Programm_Typ Prog[2] = {0};

Peter II schrieb:
> oder einfach gleich auf 0 setzen

Setzt das nicht nur den ersten der Beiden auf null?

Ralf schrieb:
> Setzt das nicht nur den ersten der Beiden auf null?

Ne, gute Idee!

Ralf schrieb:
> Setzt das nicht nur den ersten der Beiden auf null?

nein, setzt alles auf 0

Ralf schrieb:
> Erster produktiver Beitrag, habe ich grade auch bemerkt.
> Genau dadurch entstand der Fehler !

Danke, genauauf die Stelle hab ich schon vor dutzenden Posts 
hingewiesen.
Liest denn keiner meine Posts oder muss man jetzt alles vorkauen?

Robin.R. schrieb:
> Ralf schrieb:
>> Erster produktiver Beitrag, habe ich grade auch bemerkt.
>> Genau dadurch entstand der Fehler !
>
> Danke, genauauf die Stelle hab ich schon vor dutzenden Posts
> hingewiesen.
> Liest denn keiner meine Posts oder muss man jetzt alles vorkauen?

Tröste Dich. Da bist Du nicht der einzige hier.

@Theor: Danke ;-)

Robin.R. schrieb:
> Ralf schrieb:
> Erster produktiver Beitrag, habe ich grade auch bemerkt.
> Genau dadurch entstand der Fehler !
>
> Danke, genauauf die Stelle hab ich schon vor dutzenden Posts
> hingewiesen.
> Liest denn keiner meine Posts oder muss man jetzt alles vorkauen?

Stimmt, hatte ich überlesen, tut mir leid.

Können auch gerne mal über die Struktur diskutieren. Die Funktion 
verknüpft Events mit Zuständen, klar kann ich in der switch die Code 
Teile auslagern. Nur die erste switch Anweisung legt quasi die Zustände 
fest, die durch ein Event geändert werden müssen und Prog ist die 
"Warteschlange"