[MacPorts] #64356: PDAL @2.3.0_2: "zsh: trace trap" on M1

[MacPorts]

#64356: PDAL @2.3.0_2: "zsh: trace trap" on M1
--------------------------+--------------------
  Reporter:  ATL-Flaneur  |      Owner:  (none)
      Type:  defect       |     Status:  closed
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:  2.7.1
Resolution:  wontfix      |   Keywords:
      Port:  pdal         |
--------------------------+--------------------
Changes (by Veence):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 The code inside PDAL is a mess. Cheesy programming at its best.
 Excerpt from the code that causes the crash:

 {{{
 void Bounds::parse(const std::string& s, std::string::size_type& pos)
 {
     try
     {
         BOX3D box3d;
         box3d.parse(s, pos);
         set(box3d);
     }
     catch (const BOX3D::error&)
     {
         try
         {
             pos = 0;
             BOX2D box2d;
             box2d.parse(s, pos);
             set(box2d);
         }
         catch (const BOX2D::error& err)
         […]
 }}}

 So, in other words: I have to decode a line which contains coordinates.
 Let's first suppose they’re 3D and decode them as such. If that assumption
 throws an exception, then let's decode the coordinates as 2D.
 Try … catch blocks should NEVER be used that way. They should be used to
 deal with things that cannot be predicted at compile time, such that an
 out of memory error, or a file that disappears in the middle of a write
 operation. But here, it is easy to know what kind of box the user has
 given as parameter.

 In your iowa_rural_surface.json file, change the line

 {{{
  "bounds": "([-91.25, -91.18], [43.27, 43.32])",
 }}}

 into

 {{{
 "bounds": "([-91.25, -91.18], [43.27, 43.32], [0, 0])",
 }}}

 et voilà! Shazam! It now works like a charm.

 I’m not sure what causes the crash, really. I think the difference of
 behaviour between MacOS and Linux boils down to how libunwind handles
 traps (but that’s just a wild guess). Maybe on Linux/GCC the trap is
 caught by the try…catch block as if it were a software exception, and the
 execution carries on with the BOX2D decoding which should run fine. No
 such luck with MacOS/Clang, for which such traps obviously don’t enter
 into the scope of try…catch blocks.

 In any case, I would say that the MacOS executable is right to crash. The
 problem cannot be fixed by a patch, as it is by nature a flaw in the
 design of the code. I’ll escalade it upstream. In the meantime, the
 workaround of using 3D boxes anywhere should work.

-- 
Ticket URL: <https://trac.macports.org/ticket/64356#comment:18>
MacPorts <https://www.macports.org/>
Ports system for macOS