ATTN: Enabled shared Schemes

[tiennou]

I just pushed Xcode schemes in the repo (yeah, straight to master, no PR). You guys will end up with duplicate schemes until you do some cleanup manually by going to "Manage Schemes" and removing the non-shared ones.

I also brought the xcconfig files up to date (now 120 warnings, yay). I'll do a PR to fix those.

[pjrobertson]

OK, I deleted all those not ticked for ‘shared’. Everything still seems to work fine. What’s the advantage?

Most of the warnings are just "undeclared selector” warnings. Pretty easy to fix up, and should help with documentation as well… :D

On 29 Nov 2013, at 05:43, Etienne Samson notifications@github.com wrote:

I just pushed Xcode schemes in the repo (yeah, straight to master, no PR). You guys will end up with duplicate schemes until you do some cleanup manually by going to "Manage Schemes" and removing the non-shared ones.

I also brought the xcconfig files up to date (now 120 warnings, yay). I'll do a PR to fix those.

—
Reply to this email directly or view it on GitHub.

[pjrobertson]

P.S. Can the warning cleanup wait until we’ve got some of your outstanding PRs merged, incase of conflicts?
Cheers for updating your PRs, I’ll try and look over them this weekend - flying to Malaysia on Monday so my internet connection will be more stable from then on :)

On 29 Nov 2013, at 05:43, Etienne Samson notifications@github.com wrote:

I just pushed Xcode schemes in the repo (yeah, straight to master, no PR). You guys will end up with duplicate schemes until you do some cleanup manually by going to "Manage Schemes" and removing the non-shared ones.

I also brought the xcconfig files up to date (now 120 warnings, yay). I'll do a PR to fix those.

—
Reply to this email directly or view it on GitHub.

[tiennou]

The advantage is that 1) I rearranged the scheme so the Distribution target is first (no more "I built QS but it just beeps around"), 2) we can actually share the scheme settings with one another (like I think the Distribution one I pushed has the memory debug setup I use), 3) PROFIT! and 4) they're setup so that Building, Testing and debugging works out of the box (that's useful for Jenkins).

I tried to fix the warnings, but since #1147, #1601 and #1611 exists, I'm cautiously not fixing warnings in there. And I found some oddities while doing so, so I guess that's helpful in a way ;-).

[skurfer]

Only one problem: With all non-shared schemes deleted, none of the other branches can be built.

Should we all go rebase our open pulls to address this?

[tiennou]

Oh didn't think about that... I should have put this in a PR then, sorry guys :-S. I'd say a quick git merge master would work fine.

[skurfer]

Can anyone else get the application to run now? It keeps stopping with an EXC_BAD_INSTRUCTION in scannedObjects. Seems to be coming from the Contacts plug-in, so maybe we need to fix it there, but why wasn’t this happening before?

[tiennou]

I'll try as soon as I'm back from work. But I could tell the same thing about #1611 — I can't debug anything when that thing isn't merged because it breaks all over the place...

[pjrobertson]

Works fine from me, running from master. Tried force refreshing the Contacts catalog entry as well.
It’s probably worth trying to catch the problem now whilst you can reproduce, quick! :P

On 30 Nov 2013, at 00:07, Rob McBroom notifications@github.com wrote:

Can anyone else get the application to run now? It keeps stopping with an EXC_BAD_INSTRUCTION in scannedObjects. Seems to be coming from the Contacts plug-in, so maybe we need to fix it there, but why wasn’t this happening before?

—
Reply to this email directly or view it on GitHub.

[tiennou]

Quick note so I don't forget. We have 2 failing tests : testFileNaming and testFileType (I say "we" because @HenningJ, the Jenkins build bot and me see it, though only the latter for Jenkins). Here's what I've gathered :

• The first fails if you have "Show extensions" enabled on Safari (both of us have that, but Jenkins doesn't, hence the difference) because in that case name == label and thus gets ignored.
• The second one fails because we're overriding every executable UTI with public.executable in QSUTIWithLSInfoRec. If I manually step until that override takes place, I get back a hfsUTI of "dyn.agk8u" which by the looks of it is some OSType I haven't been able to decipher (yet). EDIT: Which I think is because @skurfer has something that exports that UTI and I doesn't, so I get back a opaque UTI.

[skurfer]

Actually, the UTI test has been failing for quite some time, I just never investigated why. Changing the file we test to /usr/bin/smtpd.py seems to work on my system. Yours?

I’m not sure what we should do about the naming test.

[pjrobertson]

Changing the file we test to /usr/bin/smtpd.py seems to work on my system

Worked for me. Seems like the OS isn’t that clever about figuring out the executable type from the +x bit on the file (or by checking the first few bytes of the file for #!) like we do.
Changing to use smtpd.py would be fine I think. It may still be worth keeping the test for 2to3, but doing a “conformsTo” test to make sure it conforms to public.executable.

On 30 Nov 2013, at 08:55, Rob McBroom notifications@github.com wrote:

Actually, the UTI test has been failing for quite some time, I just never investigated why. Changing the file we test to /usr/bin/smtpd.py seems to work on my system. Yours?

I’m not sure what we should do about the naming test.

—
Reply to this email directly or view it on GitHub.

[pjrobertson]

OK, I’ve got those EXC_BAD_ACCESS crashes, tracked it down to the contacts plugin as well I think. I thought it could have been to do with the fact Etienne enabled malloc history, but disabling it doesn’t help. I then tried to debug/run QS from the Contacts plugin .xcodeproj, and it worked fine - after which, it worked fine running from the QS.xcodeproj itself. Etienne did you perhaps change how binaries are built somehow so they’re incompatible with ‘old’ built binaries until they’re rebuilt? I have no idea, just a guess.

FWIW - how can I use malloc_history. I’ve done malloc_history QS_pid -callTree and I don’t really know why it’s useful :/

Reformatted by Etienne

[tiennou]

The syntax's malloc_history process_id memory_address.

That'll give you an "timeline" of what was allocated at that address (top is first). You'll see "ALLOC" and "FREE" lines separated by "--" (IIRC), it's pretty useful to know :

• where an allocation took place, in case you're curious, or you got one of "double free", or "messaged zombie" with zombies enabled (that's how I found the NSFileManager leak above.
• who put an unexpected object in the place you'd expected something else (like when you get weird "doesn't respond to selector" exception, you can see the "ALLOC" pair you expected, the unexpected "FREE" that killed your object, and the "ALLOC" of the poor object that ended up getting a wrong message.

I don't think what I enabled would have caused binary incompatibilities, I just enabled warnings and disabled building all archs in debug (which is useless since we're only targeting x86_64 atm.

I'm still not seeing EXC_BAD_ACCESS crashes (at least not in Contacts, more below). Could one of you send a gist (or other) of the output of bt all in LLDB ? Both would be nice, so we could see if it's the same code path.

But I'm getting at startup (often but not always) :

• EXC_BAD_ACCESS in either resizeTableToFit or refreshAllTasks:,
• stuff about NSKVODeallocationBreak because a task dealloc-ed without unregistering its observers,
• something that pthread_kills one of GCD's threads, which it doesn't like at all and cause the app to abort.
  I'm not more precise because I hit something like 20 of those today, and I fixed them in the task branch. I'm really wondering how people can actually use QS as it stands.

[pjrobertson]

OK, whilst trying to send my previous email and battling with problematic internet, I managed to track the problem down to… the Address Book plugin at QSABSource.m:L133

The line is:

ABAddressBook *book = [ABAddressBook sharedAddressBook];

For some weird reason, sharedAddressBook is crashing, but not for release builds, and not when running from within the AddressBook.xcodeproject project. i.e. only when debugging from Quicksilver.xcodeproj

I thought it might be a threading issue (maybe sharedAddressBook isn’t thread safe) but I checked the backtrace and Apple uses a lock, so I’m pretty sure it’s thread safe. Plus, I tried wrapping the code in a GCD block to dispatch to the main queue and the crash still occurred. Here’s the info you wanted, although I doubt it’ll be any useful

Backtrace
https://gist.github.com/pjrobertson/7727462

memory_history:
https://gist.github.com/pjrobertson/7727497

Enjoy ;-)

On 1 Dec 2013, at 09:15, Etienne Samson notifications@github.com wrote:

The syntax's malloc_history process_id memory_address.

That'll give you an "timeline" of what was allocated at that address (top is first). You'll see "ALLOC" and "FREE" lines separated by "--" (IIRC), it's pretty useful to know :

where an allocation took place, in case you're curious, or you got one of "double free", or "messaged zombie" with zombies enabled (that's how I found the NSFileManager leak above.
who put an unexpected object in the place you'd expected something else (like when you get weird "doesn't respond to selector" exception, you can see the "ALLOC" pair you expected, the unexpected "FREE" that killed your object, and the "ALLOC" of the poor object that ended up getting a wrong message.
I don't think what I enabled would have caused binary incompatibilities, I just enabled warnings and disabled building all archs in debug (which is useless since we're only targeting x86_64 atm.

I'm still not seeing EXC_BAD_ACCESS crashes (at least not in Contacts, more below). Could one of you send a gist (or other) of the output of bt all in LLDB ? Both would be nice, so we could see if it's the same code path.

But I'm getting at startup (often but not always) :

EXC_BAD_ACCESS in either resizeTableToFit or refreshAllTasks:,
stuff about NSKVODeallocationBreak because a task dealloc-ed without unregistering its observers,
something that pthread_kills one of GCD's threads, which it doesn't like at all and cause the app to abort. I'm not more precise because I hit something like 20 of those today, and I fixed them in the task branch. I'm really wondering how people can actually use QS as it stands.
—
Reply to this email directly or view it on GitHub.

[tiennou]

Hmmm. The backtrace of thread 1 looks suspicious too... Just to be sure, that's 10.9 or 10.8 ?

Can you try editing the scheme and disabling the 2 zombies things that are in Arguments as well as unchecking everything under Diagnostics ?

[pjrobertson]

10.9

I did as you said. The culprit is NSZombieEnabled
Disabling that in ‘Arguments’ makes everything works a treat ;-)

On 1 Dec 2013, at 18:51, Etienne Samson notifications@github.com wrote:

Hmmm. The backtrace of thread 1 looks suspicious too... Just to be sure, that's 10.9 or 10.8 ?

Can you try editing the scheme and disabling the 2 zombies things that are in Arguments as well as unchecking everything under Diagnostics ?

—
Reply to this email directly or view it on GitHub.

[tiennou]

Yay ! I'll push a commit to the fix-warning PR that removes those debugging flags.

[pjrobertson]

OK... so this is very ugly for one reason: I just checked out the v1.0.0 tag, and now I have no schemes to build with :(
Can we please revert this pull (well, it wasn't a pull :P) and somehow get our personal schemes back? Any ideas?

For those wondering, a temporary fix is to:

• Check out master
• Go to 'Manage Schemes' and uncheck 'shared' next to them all
• Check out whatever you wanted to originally check out

[skurfer]

Yeah, I ran into that. Probably not good in the long run. As for getting back the old ones… Time Machine? Are they the same for all of us? If so, if I find them, I can send them out.

[skurfer]

Temporary work-around: When you have no schemes, go to “Manage Schemes…” and click the +. It will have a list of all the familiar stuff. Select “Quicksilver Distribution” and add it with a different name, like “QS Distribution (Local)”. The name doesn’t have to be different, and you might not want it to be if you have build scripts expecting a specific name. It doesn’t appear to be necessary to add all the others.