Build by a coworker works, but my builds have bad bugs

[Mike Crawford]

I'm using the open source IOProxyVideoFamily to provide a virtual
frame buffer that my USB function driver will use to drive a display:

https://code.google.com/archive/p/ioproxyvideofamily/

My coworker checked his code into svn, then build binaries from trunk.
These binaries work well.

I built binaries from trunk. Sometimes I get kernel panics. Some
other times the boot progress bar stops growing before reaching the
end. The machine is fully - or mostly - booted because I can ssh in
and use the command line just as if I were using Terminal.app on a
fully booted box.

I've been beating at this for a week and remain clueless. I fear that
the only fix will be to wave a dead chicken over it. (What modern
coders call Roman Augery.)

Have you any suggestions as to how I could diagnose this?

To be clear, I'm testing both sets of binaries on just one box.
Testing on other Macs yields the same result.

IOProxyVideoFamily has some bad bugs that my coworker and I have
fixed. I expect there is at least one bug remaining. But I can't
explain why his binaries work while mine don't.

I Am Eternally In Your Debt.

Mike Crawford mdcra...@gmail.com

I'm busted flat until my driver reaches beta.
https://www.gofundme.com/help-mike-survive-for-a-month
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (Darwin-...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/darwin-drivers/darwin-drivers-garchive-96018%40googlegroups.com

This email sent to darwin-drivers...@googlegroups.com

[Phil Dennis-Jordan]

Hi Mike,

On Thu, Oct 19, 2017 at 1:20 AM, Mike Crawford <mdcra...@gmail.com> wrote:
> I'm using the open source IOProxyVideoFamily to provide a virtual
> frame buffer that my USB function driver will use to drive a display:
>
> https://code.google.com/archive/p/ioproxyvideofamily/
>
> My coworker checked his code into svn, then build binaries from trunk.
> These binaries work well.
>
> I built binaries from trunk. Sometimes I get kernel panics.

IOFramebuffer subclasses are a pain to get working, let alone getting
them to behave nicely across all OS versions you want to support. I
maintain 2 of them, it's easily the least pleasant macOS development
experience. (Good luck with 10.13's WindowServer!)

Without a panic trace it'll be hard to help with the specific problem
you're having.

> Some
> other times the boot progress bar stops growing before reaching the
> end. The machine is fully - or mostly - booted because I can ssh in
> and use the command line just as if I were using Terminal.app on a
> fully booted box.

This latter symptom is probably a crashed or frozen WindowServer process:

* If it's crashed, you'll get a report in
/Library/Logs/DiagnosticReports/ - the stack trace there will help you
debug it.
* If it's hung, you can try attaching a debugger (sudo lldb -p
<Windowserver-PID>) or sampling profiler and find out what's going on.
SIP will need to be off for this. If it's hung in the kernel, you can
find the hung thread with the kernel debugger: find the WindowServer
task and dump its stacks with showtaskstacks.

> I've been beating at this for a week and remain clueless. I fear that
> the only fix will be to wave a dead chicken over it. (What modern
> coders call Roman Augery.)
>
> Have you any suggestions as to how I could diagnose this?

Two builds of the same source code behaving differently is certainly
weird. Have you got any differences in the toolchain and SDK you're
using to build them? Release vs debug builds? What's the KP in
question? Have you tried diffing the layouts and/or disassemblies of
the binaries to identify where they diverge?

Hope that helps!

Phil