
A debugging journey - debugging a weird bug in macOS - dsr12
http://www.jimhester.com/2018/03/30/debugging-journey/
======
chrissnell
In twenty five years with various *NIX-based OSes, I've encountered a few of
these. You spend hours and hours and sometimes data digging to get to the root
of some bug and it feels so awesome when you find the ultimate cause and fix
it. Then you step back and say, what did I just do for the last two days? Two
days of your very finite existence on this Earth, spent chasing some stupid
software bug! I hope that it makes some difference in the grand scheme of
things but it almost never does. We fix these things because they are there.

~~~
webkike
I feel that, but who cares? Nothing makes a difference to anything. The things
that are important are the things we think are important

~~~
bollockitis
Exactly. Meaning is subjective. Chasing down a bug can be an exercise in
patience, diligence, and an opportunity to improve one's skill. The activity
itself is irrelevant.

------
matthewbauer
Re: apple open source version numbers: You can find the matching macOS release
by looking at the versions listed at opensource.apple.com. For instance
copyfile-138 is listed on this page:

[https://opensource.apple.com/release/macos-10126.html](https://opensource.apple.com/release/macos-10126.html)

Which corresponds to 10.12.6 release.

------
nicostouch
Interesting bug! Reading through this made me add a couple of new questions to
[http://www.debug.coach/](http://www.debug.coach/)

Could there be a bug in a library/3rd party code? Could there be a possible
race condition?

I remember recently hitting a bug in a 3rd party library in a Jar provided by
Oracle in WebLogic to do with an incorrect implementation of the W3C DOM API
causing XML validation to fail whenever attributes were present. Of course the
J-Unit tests provide a different Jar and thus a different (correct)
implementation and no bug. Took ages to track down.

~~~
oneweekwonder
[http://www.debug.coach/](http://www.debug.coach/)

You should add a ace md <textarea> below each question where I can fill in the
answers and save a pdf to share with my peers.

------
jakobegger
Ah.... very interesting. Now I know why [NSFileManager copyItemAtURL:...]
failed to return an error when the file already existed, but only with a
debugger attached. It presumably checks the errno after calling copyfile, and
ignores the return value.

I remember debugging this issue -- it took me a few hours to find out why our
test were using old data, until I found someone else reporting the issue [1],
and implemented a workaround.

[1]:
[https://forums.developer.apple.com/thread/75927](https://forums.developer.apple.com/thread/75927)

------
tzahola
errno was one of the worst ideas ever.

~~~
emmelaich
Bad implementation*, not so much a wholly bad idea.

Being sometimes a macro, sometimes not, not threadsafe? And more.

~~~
tzahola
Well... Yeah, there's some merit to _errno_ : it lets you handle errors.

Otherwise it's a horrible piece of crap:

\- It's a global (sorry, _thread-local_ ) variable, updated behind the scenes.

\- You can't tell whether a function will update errno or not by its
signature. You have to consult the documentation.

\- You can't tell the range of possible errno values unless it's explicitly
documented ( _and the documentation is kept in sync with the implementation_
).

\- Errno only communicates error metadata; the success/error bit has to be
communicated in-band via the return value (e.g. printf returning < 0).

\- _Except_ for some functions which return void (or like readdir, which
returns NULL when reaching the end of the directory, _or on error_ ) and set
errno on error.

\- In which case you better set errno to 0 before calling the function,
because while these functions set errno on failure, they not necessarily set
it to 0 on success...

