Strange problems with breakpoints appear after migration (MacBook x86_64 Sequoia to Mac M3 arm64 Sequoia)

--- This post is easier to read with BBEdit and C++ colouring.---

We get strange problems with breakpoints appearing after migration (MacBook x86_64 Sequoia to Mac M3 arm64 Sequoia).

Context

We have kept our app on the MacBook and experimented no problems.

We use clang++ and lldb. Xcode is installed but we use only CommandLineTools (no XCode project) -- and git on our lab forge.

After using the Apple migration tool, we got many problems in compiling and link-edit, in particular for dylibs.

We uninstalled all these tools and reinstalled them, using Homebrew for llvm and lld, and from AppleStore for Xcode.

We also added to our CPPFLAGS -arch arm64 -w -g -O0. We use 'make' recursively (in principle, 0 or 1 Makefile per folder.

Problems

  1. Our app crashes unexpectedly:
  • without lldb:

...Serveur: serveur.out ... stop reason = EXC_BREAKPOINT (code=1, subcode=0x1000c662c) at descripteursDeNoeuds.cpp:947:15

  • with lldb:

...Serveur: lldb serveur.out -arch aarch64 (lldb) process launch ... Process 2081 stopped

  • thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1000c6388) frame #0: 0x00000001000c6388 serveur.out`creerDescrDLING(m=1, bImpr=false) at descripteursDeNoeuds.cpp:947:15
  1. We can set breakpoints, but the location is OK relative to some files, and "pending" for the file where the crash seems to occur.

...Serveur: lldb serveur.out -arch aarch64 (lldb) target create --arch=aarch64 "serveur.out"

Current executable set to '/Users/boitet/ariane-y/Ariane-Y_prog_2013/Moniteurs/Moniteur-AY/Serveur/serveur.out' (arm64).

(lldb) br set -f initDling.cpp -l 150 Breakpoint 1: where = serveur.out`initDling(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>) + 1336 at initDling.cpp:150:30, address = 0x00000001000e0ebc

(lldb) br set -f descripteurDeNoeuds.cpp -l 886 Breakpoint 2: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations.

(lldb) br set -f descripteurDeNoeuds.cpp -l 947 Breakpoint 3: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations.

(lldb) br set -f initDling.cpp -l 153 Breakpoint 4: where = serveur.out`initDling(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>) + 1364 at initDling.cpp:153:23, address = 0x00000001000e0ed8

(lldb) br set -f descripteurDeNoeuds.cpp -l 912 Breakpoint 5: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations.

(lldb) br set -f descripteurDeNoeuds.cpp -l 3344 Breakpoint 6: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations.

==> We can set breakpoints in the caller (initDling) but not in descripteurDeNoeuds.cpp.

==> Here, we set 2 "normal" breakpoints at lines 150 and 153 of initDling.cpp, and they work well: normal stop, step-over

==> descripteurDeNoeuds.cpp contains 1 master procedure (creerDescrDepuisNoeud) that calls more specific procedures (like creerDescrDLING)

==> continuation

(lldb) process launch Process 2081 launched: '/Users/boitet/ariane-y/Ariane-Y_prog_2013/Moniteurs/Moniteur-AY/Serveur/serveur.out' (arm64)

"==============> main (du serveur) ... $$$ 4: initDling: créer les descripteurs de nœud des nœuds de cet arbre $$$ 5: initDling : --> creerDescrDepuisNoeud(j=1, 0x14a068000), i = 1, gauche(j) = 2, droit(j) = 1, benj(j) = 1 Process 2081 stopped

  • thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x00000001000e0ebc serveur.out`initDling(nomFich="../../../INCL/fichInitDling.arbDS") at initDling.cpp:150:30

    147 /*** <-TRACE / } 148 149 /**************************************/

-> 150 rc = creerDescrDepuisNoeud(j, paxml); 151 /**************************************/ 152 153 / ->TRACE ***/ if (tr>1) {

(lldb) th step-over

============================================================================ $$$ 4: creerDescrDepuisNoeud (mPar = 1, pAxmlPar = 0x14a068000) $$$ 5: creerDescrDepuisNoeud -- boucle : nomBalise = DLING, strTempo = ANNOTATIONS, trouve = 0, k = 482 $$$ 5: creerDescrDepuisNoeud -- boucle : nomBalise = DLING, strTempo = Corpus, trouve = 0, k = 483 ... ==> strange EXC_BREAKPOINT ... indNOEUD : 1 adrDESCR : 105553137336320

"==> arrêt forcé, descripteurDeNoeuds.cpp -l 966: on attend 1 seconde "==> et on exécute 'n = n / 0;' avec n = 20... mais on a ENSUITE : "==> stop reason = EXC_BREAKPOINT (code=1, subcode=0x1000c662c) at descripteursDeNoeuds.cpp:947:15

==> The instruction 'n = n / 0;' mentioned in the message is NOT executed as it was commented out (line 964). ==> There is no division by 0 in this code.

==> the last 3 lines of the trace are produced by cout instructions, at lines 962--965 ==> system-originated EXC_BREAKPOINT, at a wrong line (947) in any case!

Process 2081 stopped

  • thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1000c6388) frame #0: 0x00000001000c6388 serveur.out`creerDescrDLING(m=1, bImpr=false) at descripteursDeNoeuds.cpp:947:15 944 if (pAxml->lAttr.benj(i)) fini = true; else i = pAxml->lAttr.droit(i); 945 } // while (!fini) 946 // Imprimer le descripteur si le 2° paramètre (booléen) est vrai

-> 947 if (bImpr || bDescr) // breakpoint set -f descripteurDeNoeuds.cpp -l 947 ne va pas 948 { cout<<"--------------------------------------------------------"<<endl; 949 cout<<"--- DescrDLING("<<m<<"), "<<"pDescr="<<pDescr<<" ---"<<endl; 950 cout<<"codeBalAY : "<<pDescr->codeBalAY<<endl; (lldb)

==> but we are at line 966, not 947

==> And at line 967, there is nothing special:

if (bImpr || bDescr)		//  breakpoint set -f descripteurDeNoeuds.cpp -l 947 ne va pas
{	cout<<"--------------------------------------------------------"<<endl;
	cout<<"--- DescrDLING("<<m<<"), "<<"pDescr="<<pDescr<<" ---"<<endl;

==> continuation, interruption and backtrace

(lldb) p (bImpr || bDescr) (bool) true (lldb) p bImpr (bool) false (lldb) p bDescr (bool) true (lldb) (bool) true

(lldb) bt

  • thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1000c6388)

    frame #0: 0x00000001000c6388 serveur.out`creerDescrDLING(m=1, bImpr=false) at descripteursDeNoeuds.cpp:947:15

    frame #1: 0x00000001000dd710 serveur.out`creerDescrDepuisNoeud(mPar=1, pAxmlPar=0x000000014a068000) at descripteursDeNoeuds.cpp:3406:41

...

==> ==> After that, we are blocked, no step or continue instruction works. Then we quit.

We could not find this exact subcode (0x1000c6388) on the Web. We found a post mentioning a similar problem, with another subcode (0x100308448). https://stackoverflow.com/questions/45413088/error-exc-breakpoint-code-1-subcode-0x100308448

But the author worked under Xcode, and we don't.

It would help if you put your preformatted text into a code block. See Quinn’s Top Ten DevForums Tips for advice on how to do that.

I’m very confused by your post, so lemme start out with some thing simple. You wrote:

without lldb … stop reason = EXC_BREAKPOINT

I don’t understand this. The stop reason message clearly indicates that you’re running your program under LLDB. So how can that be “without lldb”?

It looks like you’re building a standalone executable rather than an app. If so, what happens if you run the program from Terminal directly?

I’m presuming it’ll crash there too. If so, that should generate a crash report. Please post the crash report here. See Posting a Crash Report for advice on how to do that.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We have tried BOTH ways (on Sequoia/arm64):

  • without lldb, that is "serveur.out"
  • with lldb, that is "lldb server.out"

Most of the post shows the second call (with lldb). We are NOT creating an "app" (in the macOS sense) at the moment. We start our programs from the Terminal (Serveur on 1 window, Client on another window, both in the same machine or not -- communication is done by sockets)

==> Since then, we have tried to change from clang to another C++ compiler.

  • Still problems with gcc
  • The problem disappears with c++ !

We are now sure that the problem comes from the amr64 version of clang, because exactly the same code runs without problems on Sequoia/x86_64/clang.

Strange problems with breakpoints appear after migration (MacBook x86_64 Sequoia to Mac M3 arm64 Sequoia)
 
 
Q