(I did find a bunch of undefined behavior being hit, though, which I Anything in particular you'd like to point out?
#MAC GDB INSTALL HIGH SIERRA CODE#
> but I can't understand the code in the C/C++ The add_target call is in i386-darwin-nat.c:_initialize_i386_darwin_nat > it seems a little fishy that darwin-nat.c doesn't have any sort of > gdb`push_target(struct target_ops *) at target.c:653. > including this one crash with a null pointer dereference in > follow the debuggee to completion without incident, but the ones after and > Could someone confirm this for me? Commits before this one can successfully It if caused some breakage, it's something else.
That commit can't be the culprit for the issue reported in this bug,īecause that commit is recent, it is in master only, not in 8.1. > running /Users/saagarjha/Git/bisect-test.sh I do hope none of you take it personally–but if you're looking for things to improve, this is one thing I think you should focus on. I do apologize for the vitriolic tone here, but I'm extremely frustrated at the amount of time I had to spend finding this when it should have been a rather trivial task. I'm aghast that it's possible for such clearly broken patches to land in the master branch. Others dereference null pointers or overflow ints during startup, which really threw off my bisect script with false positives: I had to restart the bisect from the beginning at least half a dozen times because it homed in on the wrong bug. Many intermediate commits are broken, as in they *literally don't build on macOS*, because someone forgot a header file or messed up a Makefile. Does GDB have *no* automated testing or continuous integration whatsoever? Putting aside the fact that any such infrastructure would catch simple bugs like this one, which are easy to reproduce, it would have also made my life bisecting a lot easier. Just as a FYI, confirming this particular commit took well over two days and testing over two hundred revisions, which is something that I find as an outside observer to be truly horrible. Let me know if you're curious in seeing them.) (I did find a bunch of undefined behavior being hit, though, which I *do* have patches for. From a cursory glance, it seems a little fishy that darwin-nat.c doesn't have any sort of add_target call in it, but I can't understand the code in the C/C++ frankenstein state it's in right now, so I wasn't able to come up with a fix.
Running /Users/saagarjha/Git/bisect-test.shį6ac5f3d63e03a81c4ff3749aba234961cc9090e is the first bad commitĬommit f6ac5f3d63e03a81c4ff3749aba234961cc9090eĬould someone confirm this for me? Commits before this one can successfully follow the debuggee to completion without incident, but the ones after and including this one crash with a null pointer dereference in gdb`push_target(struct target_ops *) at target.c:653.
0 kommentar(er)
