Bitte um Hilfe: Ich finde die Ursache der komischen Fehler nicht.

[Alex (haidanai)]

Hallo,

Bei einem größeren Projekt mit SAMD21E und AT Studio 7 lies sich bis vor 
Kurzem das Programm ohne Fehler übersetzen. Nach einigen 
(unverdächtigen) Änderungen wirft der Linker auf einmal komische 
Fehlermeldungen aus - siehe Anhang.
Weil ich schonmal in der .h den Strichpunkt hinter einer Funktion 
vergaß,
weiß ich was für eine Flut an seltsamen Meldungen aufpoppen, nur wegen 
winziger Fehler.
Sowas vermute ich auch, habe aber schon die ganzen Differenzen zur 
fehlerfreien Version gecheckt. Die sind alle unverdächtig.
Weiß jemand irgend was, wo ich suchen könnte?

[Jim M. (turboj)]

Das ist die benötigte Infrastruktur für einen printf() function call. 
Mach den mal raus.

Ansonsten probiere mal "-lnosys" als Linker Option...

[Udo S. (urschmitt)]

Alex schrieb:
> Sowas vermute ich auch, habe aber schon die ganzen Differenzen zur
> fehlerfreien Version gecheckt. Die sind alle unverdächtig.

Dann suche systematisch. Immer nur eine Änderung und übersetzen.

[Ein T. (ein_typ)]

Udo S. schrieb:
> Alex schrieb:
>> Sowas vermute ich auch, habe aber schon die ganzen Differenzen zur
>> fehlerfreien Version gecheckt. Die sind alle unverdächtig.
>
> Dann suche systematisch. Immer nur eine Änderung und übersetzen.

"git bisect" kann helfen, daß man nicht jede einzelne Änderung testen 
muß.

[Alex (haidanai)]

> Ansonsten probiere mal "-lnosys" als Linker Option...
Wie stellt man das im AT Studio ein?
Unter Project-Properties-Linker-???

> "git bisect" kann helfen, daß man nicht jede einzelne Änderung testen
muß.
Danke schonmal. Werde ich ausprobieren.

[Arduino F. (Firma: Gast) (arduinof)]

Alex schrieb:
> Bitte um Hilfe: Ich finde die Ursache der komischen Fehler nicht.
Finde ich auch nicht.

Und ich habe wirklich gesucht.
Mehrfach.

Alex schrieb:
> Sowas vermute ich auch, habe aber schon die ganzen Differenzen zur
> fehlerfreien Version gecheckt. Die sind alle unverdächtig.

Was soll mir das Wort "unverdächtig" in diesem Zusammenhang sagen?

[Peter D. (peda)]

Alex schrieb:
> habe aber schon die ganzen Differenzen zur
> fehlerfreien Version gecheckt. Die sind alle unverdächtig.

Dann nimm die fehlerfreie Version, ob sie weiterhin fehlerfrei 
compiliert.
Und dann füge die Änderungen nacheinander ein.

[Alex (haidanai)]

ok, mit "-lnosys" als Linker Option kommen jetzt zusätzliche Meldungen 
-Anhang.

[Alex (haidanai)]

Oh mann,
mein EntwicklungsleiDer hat Configuration "Debug" und "Release" 
eingerichtet.
Wenn ich auf Debug stelle, kommen die komischen Fehler, wenn ich auf 
Release gehe, sind sie weg.
Wie finde ich das raus???

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Alex schrieb:
> Wie finde ich das raus???
Vergleiche die Toolchain-Einstellungen und Parameter für diese beiden 
Makepfade.

[Sebastian S. (amateur)]

Wohl dem, der eine Revisionsverwaltung hat und diese auch nutzt.

Die gibt es für lau im Netz und wenn man will, kann man jederzeit den 
"Rückwärtsgang" einlegen.
Natürlich muss man sich angewöhnen diese auch zu nutzen und dann - "Oh 
wie schrecklich!" - einen Kommentar abgeben um die Änderung zu 
bezeichnen.

[Alex (haidanai)]

> Wohl dem, der eine Revisionsverwaltung hat und diese auch nutzt
Ich benutze Tortoise Git!
Das git bisect hat mir nix gebracht, da ich genau weiß welche Version 
ging
und bei der Nächsten ging es nicht mehr...

[Flunder (flunder)]

Und wenn alles andere nix nützt, könnte miteinander reden vielleicht was 
bringen. Einfach mal fragen, welche Unterschiede er zwischen Debug und 
Release macht.

[Flunder (flunder)]

Sebastian S. schrieb:
> Wohl dem, der eine Revisionsverwaltung hat und diese auch nutzt.
Wer die vor allem nutzt, um Änderungen von Kollegen asap rückgängig zu 
machen, hat ruckzuck andere Probleme, die git nicht lösen wird.

Ansonsten : ja, eine Versionsverwaltung und deren regelmäßiger Gebrauch 
helfen oft sehr.

[Alex (haidanai)]

> Und wenn alles andere nix nützt, könnte miteinander reden vielleicht was
bringen.
Das ist kaum möglich - leider

Also kommen jetzt keine weiteren sachdienlichen Hinweise mehr?

[Wastl (hartundweichware)]

Alex schrieb:
> Also kommen jetzt keine weiteren sachdienlichen Hinweise mehr?

Hast schon mal versucht alle *.obj Files im Projekt von Hand
zu löschen damit auch keine "Leichen" von der Vorgeschichte
vorhanden sind?

[Thomas Z. (usbman)]

Kann es sein dass es sowas wie ein Debug_Printf gibt ev in einem Macro 
versteckt?

[Udo S. (urschmitt)]

Alex schrieb:
> Das ist kaum möglich - leider

geil

Kündigen

[Arduino F. (Firma: Gast) (arduinof)]

Alex schrieb:
> Also kommen jetzt keine weiteren sachdienlichen Hinweise mehr?

Ich unterscheide ganz gerne zwischen technischen Problemen und sozialen 
Problemen.

Soziale Probleme kann man meist dadurch bearbeiten, dass man darüber 
redet.
Und während man darüber redet, ändert sich das Problem, oder die 
Einstellung dazu ändert sich. Was beides im Endeffekt auf das gleiche 
herausläuft.
Auf technische Probleme lassen sich die sozialen Lösungsstrategien 
selten anwenden.

Bei technischen Problemen:
1. Problem analysieren
2. Lösung erarbeiten
3. Lösung durchsetzen.

Punkt 1 erfordert umfangreiche Kenntnisse über das Problem selber, über 
den Kontext.
Die Anwendung technischer Strategien, auf soziale Probleme, führen gerne 
zu gruseligen Lösungen, z.B. Guillotine, Elektrischer Stuhl usw.

War das sachdienlich?

[Niklas G. (erlkoenig)]

Hässlicher Trick: Die fehlenden Funktionen (_write etc.) als Dummy leer 
implementieren. Disassembly erzeugen und schauen wo malloc(), printf(), 
puts() etc. aufgerufen werden.

Thomas Z. schrieb:
> Kann es sein dass es sowas wie ein Debug_Printf gibt ev in einem
> Macro
> versteckt?

Wäre auch meine Vermutung. Oder: es wird assert() genutzt, welches 
standardmäßig printf() und abort() aufruft. Im Release-Build wird per 
-DNDEBUG das assert() deaktiviert.

[Alex (haidanai)]

> Oder: es wird assert() genutzt, welches standardmäßig printf() und abort() 
aufruft.
Ja genau, ich habe assert() drin. Aber das hatte ich auch schon, als es 
noch keine Fehler gab. Irgend wie / wo muss man dem assert das printf 
abschalten können?

[Niklas G. (erlkoenig)]

Alex schrieb:
> Irgend wie / wo muss man dem assert das printf aqbschalten können?

Indem du eine eigene __assert_func implementierst und dort halt kein 
printf verwendest.

[Alex (haidanai)]

Also, ich habe meine eigene assert() geschrieben.
Damit konnte ich mein Problem lösen.
Vielen Dank für eure Hilfe, die den wichtigen Hinweis auf printf <= 
assert
gegeben hat.
Damit ist für mich das Thema erledigt.

[Niklas G. (erlkoenig)]

Alex schrieb:
> Also, ich habe meine eigene assert() geschrieben.

Achtung, da gibt es ein paar Fallen wenn man es "from Scratch" macht 
(statt z.B. die Standard-Implementierung anzupassen).