I know this is rather vague but does anyone have any pointers as to why a completion handler does not get run in the release build but does run in the debug build.
I have not idea where to begin trying to solve this other than changing the code to not use a completion handler.
Any pointers would be welcome.
App is written in Swift and built for OS X 10.10
UPDATE
I just modified the code to send a NSNotification rather than run the completion handler and now things work fine. I still have the completion handler code in but its not being called.
We can't read minds. Can't help you if you don't show us the real code.
BUT. It it possible that you've come across a compiler bug. I've had a similar problem, where the Swift compiler would generate incorrect code in optimized (Release) build — but the same thing would work fine in Debug. (rdar://18906781) I've also heard of other production apps written in Swift that simply do not work correctly in optimized builds (and so are shipped unoptimized).
Try reworking the code to achieve the same thing with different code — maybe you'll work around the bug.
If you have the time, I encourage you to try narrowing the bug as much as possible to make a test case and reporting it on http://bugreport.apple.com.
Related
I am new to MacOS and especially its lower level stuff, I built a CLI program to inject a dylib into a vulnrable process. It works fine, but I wanted to make a GUI program to do this, but now on my call to
proc_listallpids(NULL, 0);
the return value is always 0. Looking into some source code I found:
if ((error = proc_security_policy(PROC_NULL, PROC_INFO_CALL_LISTPIDS, type, NO_CHECK_SAME_USER)))
return (error);
But I was not able to find the source code for this function to find out why it fails(assuming this is the reason it does fail)
Is proc_listallpids() not allowed to be called from Apps? If so is there a way I can still make a GUI program but use this function? I was kind of thinking this might be to do with restrictions for the appstore but I wouldn't want my program on the appstore
Also I was wondering if there is a better site to go for topics like this.
The answer was App Sandbox, not sure if this is worth keeping around or not. I turned it off in the project settings and the function works now
I am currently testing the GTK Application that I built on windows using the MSYS2 64bit shell.
For the program to be able to run outside of the shell, I packed all the required DLLs with it as well as the following:
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders\\*
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache
FOLDER\share\glib-2.0\schemas\gschemas.compiled
FOLDER\share\icons\Adwaita\\*
FOLDER\share\icons\hicolor\\*
The good news is: It works :) And it also works flawlessly on another PC that doesnt have GTK/Msys2/whatever installed.
The bad news is: On yet another PC (I have tested it on 2 other Systems other than my developing System so far, one one of them it works flawlessly), the program itself works, but the GUI is not rendered sharply (texts are blurry).
Do you guys have any idea on what could be the reason for that? I'm guessing it could be one of the following:
The affected system could have some general display problems that have nothing to do with my app.
The gschemas.compiled file does not suit the affected system. In that case I would probably have to create that file dynamically, but I have no idea how to do this.
I am missing some file from GTK or Glib that would solve the problem.
I am thankful for any help :) Compiling/Deploying a GTK App for Windows has proven to be a pain in the ***, but since (almost) everything works now, I feel like its not much that I am missing unless I have overseen something critical.
Regards,
tagelicht
Given the way you created your package, my bet is that you are missing some components, making the drawing code use some fallback routines, hence the "sharp" drawing.
Try to run the application in command line on the machine where your have the problem, to see if there are some unusual warnings you don't have when running it on your machine.
See also my answer on how to distribute a GTK+ application on Windows.
I have an embedded project which runs on a 68332 processor target (68k family). There is no OS on the target. We have a custom simulator that will allow our code to execute within Windows. The simulator is completely without our control to modify. Basically the simulator is executing the machine code which isn't very good when you need to debug. What I would really like to do is interface a debugger to allow us to debug at the source level rather than at the machine/assembly level. Has anyone ever done such a thing? Is there a spec that debuggers support? Perhaps would something like gdb work for this? Any advice is appreciated.
This is not necessarily an answer to your question - I'm not familiar with hooking up an existing 3rd-party debugger to a program executing inside a VM so I can't advise about that.
However, you control the source of your simulator so you can try implementing an interface (maybe a local socket, etc.) where your simulator keeps reporting status information about the code that's executing and links it up with source files by reading debug information from some generated debugging database. You'd likely have to support reading the debugging format of the compiler that compiles your 68k code and then use that information to link back assembly instructions to source code lines.
This way you're effectively implementing a debugger, but since you already have the simulator (a VM really), that's probably not too much of extra work - the simulator already has all state information about the executing 68k code, you just need a way to temporarily pause execution and extract state information during pause. Stepping through code after that is probably a trivial repeat of these steps.
I'm trying to build an automated test to check that methods called outside of the current deployment target are handled correctly. Here's a concrete example:
My app is set to use the Mac OS X 10.8 sdk and the deployment target is set to 10.6.
I often use the setTimingFunciton: method. It was introduced in 10.7.
[[NSAnimationContext currentContext] setTimingFunction:[CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionEaseIn]];
In most cases I correctly bounded this method call with a check to ensure the method exists or that the OS was the correct version or later. But I missed one. And it's in a rarely executed code path, so even beta testing didn't notice it. It only came back to bite me much later.
I'd like to build an automated way to test for things like this that can be deployed on an integration server or other such scripted regression test. It seemed like something there must be a way to check for automatically.
Recompiling with the 10.6 sdk unfortunately results in many errors, most due to "modern obj-c". These, of course, are not errors when using the 10.8 sdk. Being careful, I can pick through the errors and find the method calls -- but that's overly complicated and manual.
Does anyone know of a way to statically check these sorts of things that doesn't involve a human picking through hundreds of lines of false-errors?
P.S. I've read this: How to check if not available methods are used if deployment target < base sdk?
Which recommends another manual flow for digging through them. The problem is, the human method failed me. I missed one. I'd like something a bit more certain.
I've used the technique from this answer and it has worked great. Totally automatic and it doesn't miss anything.
Here is an idea. undef and redefine the availability macros so they contain something that Clang will object to but will otherwise not affect program flow. Run Clang.
I'm having a problem getting OpenMP and OpenCV to play nicely with a new project in Xcode. The project in its current state does nothing but grab frames from the default camera and put them into a window. This functionality works. However, I would like to grab the frames in a separate thread, and I was hoping I could get some experience with OpenMP.
Merely checking the checkbox to enable OpenMP in Xcode wreaks havoc. The program, while it will compile, load and run just fine, will not respond to any events -- period. It just sits there, drawing grabbed frames. (I do get the OS X beachball, too, even though it's running fine.) I eventually have to force quit the app or kill it from Xcode. Keep in mind I get this behavior even without any OpenMP #pragmas -- I have only to enable the option in Xcode.
Any ideas on how to solve this?
I'm just guessing here. You might need to make sure that all OpenGL drawing commands are called from one thread.