|
Is there a quick way to test if the CFI sanitizer works? Some way to trigger it that won't be caught at compile time?
|
#
?
Jul 22, 2017 13:17
|
|
|
|
| # ? May 22, 2024 10:48 |
|
|
Luigi Thirty posted:It looks like the problem was the two versions not cooperating. xcode-select told me I had the beta version enabled which lacked a 10.3 runtime. 8.3.3 was trying to start the simulators with 10.3 and failing. 9.0 was failing to start them because they were in an invalid state. I swapped back to Xcode.app, killed CoreSimulatorService and the simulator starts now. I'm glad you got it working. If anyone has a chance, please try running Xcode 9 betas side-by-side. We are installing CoreSimulator as a shared service now to eliminate these problems once and for all (at least after Xcode 8 sails off into the sunset). Please report any problems - this is a dry run for the future so a little bit of bug reporting now may save a lot of pain later.
|
|
#
?
Jul 23, 2017 05:40
|
|
|
Props to the Xcode 9 team for focusing on responsiveness and performance--coming from Eclipse on the same machine is like night and day.
|
|
#
?
Jul 23, 2017 13:12
|
|
|
One more question about the CFI sanitizer that will go unanswered: is it supported on the iOS simulator? because I'm getting this linker error: LLVM ERROR: unsupported relocation with subtraction expression, symbol '_malloc' can not be undefined in a subtraction expression. I'm 99.999% certain CFI is to blame because if I remove -fsanitize=cfi from cflags, it works
|
|
#
?
Jul 23, 2017 21:03
|
|
|
Seems I have to use -fvisibility=default instead of -fvisibility=hidden?  e: nope! hackbunny fucked around with this message at 21:52 on Jul 23, 2017 |
|
#
?
Jul 23, 2017 21:10
|
|
|
I'm not sure the CFI sanitizer is actually an Apple-supported technology at all.
|
|
#
?
Jul 24, 2017 00:48
|
|
|
Oh ugh. Should I just forget about it then?
|
|
#
?
Jul 24, 2017 01:28
|
|
|
Based on the usernames that contributed to related functionality, it looks like that sanitizer is Google's thing.
|
|
#
?
Jul 24, 2017 03:08
|
|
|
Sanitizer is a bit of a catch-all brand; basically anytime Google writes a runtime analysis tool, they call it a sanitizer now. The sanitizers vary a lot in importance, quality, and ease of porting, and Google always coming out with new ones; our focus has been on supporting and improving the most useful ones rather than trying to keep pace. That alone takes a lot of work: while Google does generally make an effort to port new sanitizers to Darwin, all that really means is that you can run a sanitizer on a pure C/C++ project, which is Not Really A Thing for most of our developers (the projects I work on being a notable exception). For example, in order for TSan to work, it has to know about all the library code that synchronizes between threads, which means we had to teach it about a bunch of things with GCD, libdispatch, the ObjC and Swift language runtimes, etc. And of course there are things like this that probably just come down to linker differences between platforms and targets.
|
|
#
?
Jul 24, 2017 03:54
|
|
|
I've had good luck with getting useful results out of google's darwin ports before they officially supported by Apple, but it's definitely not ever just "build clang, pass flag to clang, get bugs detected". For TSan I had to hack together a super-minimal xctest runner and a naive implementation of the small bit of libdispatch that our tests rely on, and that was all only a viable thing to do because the code I was actually trying to test was platform-independent C++ and not something that actually leveraged any of the Apple threading technologies. UBsan was easier, but still required quite a bit of fiddling.
|
|
#
?
Jul 24, 2017 04:52
|
|
|
I'm trying to have my CPU emulator execute instructions in a background thread. So I can debug the instruction processing, it executes an instruction every second and then updates the UI on the main thread. I have this function that just puts 10GB of data onto the queue after a few seconds because multithreading is hard:code:Sure looks pretty though. 
|
|
#
?
Jul 24, 2017 08:28
|
|
|
hackbunny posted:One more question about the CFI sanitizer that will go unanswered: is it supported on the iOS simulator? because I'm getting this linker error: LLVM ERROR: unsupported relocation with subtraction expression, symbol '_malloc' can not be undefined in a subtraction expression. I'm 99.999% certain CFI is to blame because if I remove -fsanitize=cfi from cflags, it works I'm not sure what you mean by the CFI sanitizer? Do you mean the undefined behavior sanitizer? Thread sanitizer? Something else?
|
|
#
?
Jul 24, 2017 08:35
|
|
|
eschaton posted:I'm not sure what you mean by the CFI sanitizer? Do you mean the undefined behavior sanitizer? Thread sanitizer? Something else?
|
|
#
?
Jul 24, 2017 10:01
|
|
|
Well, it may not be officially supported but it works. I tried it with these test cases and it does trap, although diagnostic messages are unsupported (clang: error: unsupported option '-fno-sanitize-trap=cfi-derived-cast,cfi-unrelated-cast,cfi-nvcall,cfi-vcall'). Not that it's usable in development builds anyway, LTO is too slow. E: it seems to break debugging as well, binary-to-source mapping seems broken I understand Apple's faith in their mobile OS but I'd still like to harden my app: an app exploit may not be usable to attack the system but it will still put the app's data at risk. Will we ever get official support for _FORTIFY_SOURCE, -fstack-protector, etc.? (how aren't they the default?) hackbunny fucked around with this message at 11:44 on Jul 24, 2017 |
|
#
?
Jul 24, 2017 11:39
|
|
|
We're working on some things in this area.
|
|
#
?
Jul 24, 2017 16:04
|
|
|
Luigi Thirty posted:I'm not sure what the right way to organize this is... There are about a million ways to do this. I'd probably have a Timer refreshing your UI once a second with the CPU work off running its own thing, occasionally updating its status on the main thread. As much as I love using GCD for everything, a CPU simulator is not a bad place for Thread.
|
|
#
?
Jul 25, 2017 00:12
|
|
|
What's a reliable way to make sure a script that updates Info.plist is run every time the app is built? I've tried pretty much everything I could think of, but Xcode stubbornly caches the result of the build script phase no matter what I put as its inputs or outputs. I've even tried giving the script an input file that's guaranteed to change every time (because I write a different UUID to it every time), but Xcode doesn't care and even lies in the build log, saying it ran the script when it clearly didn't Will an "external build system" target that the app target depends on work? e: only tool I've found that will parse the incremental build database is, as far as I can tell, in Haskell. Please don't make me do this. Thanks hackbunny fucked around with this message at 15:25 on Jul 25, 2017 |
|
#
?
Jul 25, 2017 15:20
|
|
|
Alright I think I've found an acceptable hack: a build script with no inputs or outputs writes a unique UUID to a file under DERIVED_FILE_DIR, and the other build scripts specify that file as one of their inputs. As a result, all scripts are executed every time the app is built, and the unique build number and my custom Info.plist fields with revision control information are filled in correctly e: motherfucker of course DERIVED_FILE_DIR doesn't exist after a clean. But CONFIGURATION_TEMP_DIR does, and I'm already using a user-defined variable to set the path to the UUID file, so I only have to change the path in one place. Up yours, Xcode! e: btw I really appreciate the subtle "gently caress you" in caching the output of the script run phase in the build log to suggest the script is run every time  gently caress you right back Xcode!
hackbunny fucked around with this message at 16:20 on Jul 25, 2017 |
|
#
?
Jul 25, 2017 16:10
|
|
|
What the hell are you doing that you need to automatically rewrite Info.plist?
|
|
#
?
Jul 25, 2017 17:01
|
|
|
A unique build number (CFBundleVersion) mainly, which I simply set to the output of date -u "+%Y%m%d%H%M%S", which can't really be cached as it changes every second. Recently, I've been adding the source code commit id and tags as well
|
|
#
?
Jul 25, 2017 18:04
|
|
|
Can you preprocess the info.plist and generate a .h with your script instead? Xcode might cache that too, or maybe that's already what you're doing.
|
|
#
?
Jul 25, 2017 18:08
|
|
|
hackbunny posted:A unique build number (CFBundleVersion) mainly, which I simply set to the output of date -u "+%Y%m%d%H%M%S", which can't really be cached as it changes every second. Recently, I've been adding the source code commit id and tags as well Are you doing this on a CI instance or your own computer?
|
|
#
?
Jul 25, 2017 18:27
|
|
|
pokeyman posted:Can you preprocess the info.plist and generate a .h with your script instead? I've done projects that have script-generated .h files (among other types) and never had a problem, so long as the input and output file parts of the build script phase were set correctly. IIRC, Xcode won't run the script if the specified output exists and is newer than the input (which is exactly what it should be doing), if you leave off the input and output file names then it runs the script every time, but might cache files the script is generating since it doesn't know the script is generating them. There's a blog post floating around somewhere about how to increment the build number in info.plist every build that makes both Xcode and version control happy.
|
|
#
?
Jul 25, 2017 18:56
|
|
|
Doh004 posted:a CI instance lol yeah, in my dreams maybe
|
|
#
?
Jul 25, 2017 19:10
|
|
|
fastlane also has increment_build_number but maybe you have a reason for incrementing it even when just testing with devices/simulators?
|
|
#
?
Jul 25, 2017 22:29
|
|
|
Does anyone know of any good 3.5mm headphone/microphone splitters on iPhone? Apparently it's incredibly difficult to find one that will work as expected? I found one that works partially - https://www.amazon.com/StarTech-com-headsets-separate-headphone-microphone/dp/B004SP0WAQ But the problem is that the microphone input bleeds into the headphone output. The only other option seems to be soldering a 1600 Ohm resistor into the microphone line (seriously) https://electronics.stackexchange.com/questions/38452/electronic-aspects-of-iphone-3-5mm-audio-output
|
|
#
?
Jul 25, 2017 23:32
|
|
|
hackbunny posted:A unique build number (CFBundleVersion) mainly, which I simply set to the output of date -u "+%Y%m%d%H%M%S", which can't really be cached as it changes every second. Recently, I've been adding the source code commit id and tags as well Here is how Twitch solved this problem
|
|
#
?
Jul 26, 2017 00:08
|
|
|
Vesi posted:fastlane also has increment_build_number but maybe you have a reason for incrementing it even when just testing with devices/simulators? I don't use fastlane and if I cared to only run the script for release builds, I'd just check "Run script only when installing" I considered this but I don't like the idea of an aggregate target. The upside of using the preprocessor, on the other hand, is that Info.plist can stay in the source directory instead of being a derived source, which goes in a per-configuration path and breaks things like the Info pane of build targets that require a configuration-agnostic location e: which would have really simplified defining that document type and UTI hackbunny fucked around with this message at 00:46 on Jul 26, 2017 |
|
#
?
Jul 26, 2017 00:40
|
|
|
I’m pretty sure at work we generate an InfoPlist.h via an aggregate target that has a run script build phase, then we set the build settings to preprocess the Info.plist and point it at the generated .h. I don’t recall having any issues with stale Info.plist files making it into the build. But maybe I should check, if that doesn’t seem to be working for you. I suspect a run script build phase in the app target as the first possible step would work too.
|
|
#
?
Jul 26, 2017 01:20
|
|
|
pokeyman posted:I’m pretty sure at work we generate an InfoPlist.h via an aggregate target that has a run script build phase, then we set the build settings to preprocess the Info.plist and point it at the generated .h. I don’t recall having any issues with stale Info.plist files making it into the build. But maybe I should check, if that doesn’t seem to be working for you. I suspect a run script build phase in the app target as the first possible step would work too. No, it should work in fact, and play better with Xcode than what I'm doing right now (reminder: I set the project's Info.plist to a script-generated file in the derived sources directory, where the Info.plist editor can't find it). It's just the only thing I haven't tried yet
|
|
#
?
Jul 26, 2017 09:35
|
|
|
Why do I have to use the preprocessor, this is dumb, I want to use a partial Info.plist like the asset compiler does 
|
|
#
?
Jul 26, 2017 11:58
|
|
|
hackbunny posted:lol yeah, in my dreams maybe Why not if I may ask? Could be a service or local, just curious. Vesi posted:fastlane also has increment_build_number but maybe you have a reason for incrementing it even when just testing with devices/simulators? This is what we use. Whenever we merge a PR into master, we run tests on CI and then increment the build number with fastlane, build an ad hoc build with that number, deploy it on Crashlytics, and then have the CI instance commit the version update and push it to the remote repo (which CI knows not to kick off another build from it). I understand everyone's use case isn't like this, but I'm just curious as to why you'd need to update a build version for local development.
|
|
#
?
Jul 26, 2017 11:58
|
|
|
Doh004 posted:Why not if I may ask? Could be a service or local, just curious. Because I wish I had the time to set up CI
|
|
#
?
Jul 26, 2017 12:53
|
|
|
hackbunny posted:Because I wish I had the time to set up CI Barring any sort of legal concerns (again, not familiar with your setup), it takes like 2 seconds to get set up on CircleCI (or TravisCI). Their macOS instances have gotten much better over the past two years.
|
|
#
?
Jul 26, 2017 13:19
|
|
|
We are an Atlassian shop, do those integrate with JIRA and Bitbucket? I'm not thrilled by the idea of setting up Bamboo, I'd be glad to use literally anything else Besides it seems pointless to have CI without automated tests e: oh ugh CircleCI's on-premise pricing seems... a little high e: I understand what you mean with "legal issues", yeah no  stuff
hackbunny fucked around with this message at 13:50 on Jul 26, 2017 |
|
#
?
Jul 26, 2017 13:46
|
|
|
hackbunny posted:We are an Atlassian shop, do those integrate with JIRA and Bitbucket? I'm not thrilled by the idea of setting up Bamboo, I'd be glad to use literally anything else Yeah, I believe they integrate with Bitbucket as well but I also hadn't looked into a hosted solution so I wasn't familiar with its pricing.
|
|
#
?
Jul 26, 2017 14:42
|
|
|
If I’m writing an 8-bit computer emulator for macOS and I want to be able to construct and blit a 320x240 indexed-color bitmap into a window, which of the graphics frameworks would work best for me in TYOOL 2017? I peeked at other projects on Github and seen people use OpenGL/GLUT, Metal, Core Graphics, but a lot of these projects are pretty old. My desktop graphics experience is pretty much drawing bitmaps with GDI unless programming an Amiga counts. I do know how to use QuickDraw but that’s a little out of date. Luigi Thirty fucked around with this message at 23:41 on Jul 26, 2017 |
|
#
?
Jul 26, 2017 23:38
|
|
|
My first quick and dirty attempt would probably just involve a layer-backed NSView subclass for wiring into the UI, and using a CG bitmap to draw the layer's contents. I did basically that minus the layer long ago (~15 years, yikes) for a MacHack project rendering a remote frame buffer that was being streamed at my app via TCP and it worked well enough. Edit: In the Core Animation intro docs, this talks about providing a layer delegate: quote:If your delegate implements the drawLayer:inContext: method, Core Animation creates a bitmap, creates a graphics context to draw into that bitmap, and then calls your delegate method to fill the bitmap. All your delegate method has to do is draw into the provided graphics context. Should be a good place to start. eschaton fucked around with this message at 23:52 on Jul 26, 2017 |
|
#
?
Jul 26, 2017 23:47
|
|
|
I would suggest Core Graphics if you're ok with CPU, GL or Metal for GPU. With Core Graphics you might make a view subclass and override drawRect (you have a current CGContext available to you there), or you can blit to a bitmap context and set the resulting image on an image view. edit: oh yeah Core Animation layer is probably more sensible than image view.
|
|
#
?
Jul 26, 2017 23:47
|
|
|
|
| # ? May 22, 2024 10:48 |
|
|
Luigi Thirty posted:If I’m writing an 8-bit computer emulator for macOS and I want to be able to construct and blit a 320x240 indexed-color bitmap into a window, which of the graphics frameworks would work best for me in TYOOL 2017? I peeked at other projects on Github and seen people use OpenGL/GLUT, Metal, Core Graphics, but a lot of these projects are pretty old. I'd second what others say: Do the minimal dumb slow thing and get stuff working first. When you want to optimize you can use a Metal view. If you have more complicated needs (eg rendering in a separate process) use Metal to draw into an IOSurface-backed texture and set the CALayer's contents to the IOSurface. You can send IOSurfaces across XPC and create a swap-chain for your presentation buffer vs back-buffer.
|
|
#
?
Jul 27, 2017 00:43
|
|