We've got a fairly mature cross-platform game engine which we've had running on OSX for several years now without a hitch; we recently upgraded the game from SDL 1.2.15 to 2.0, and at some point in the conversion, I goofed something up and now we have a bizarre problem where the app launches just fine from the terminal, but when you launch the app from a double-click in the Finder, it just bounces once in the dock and just goes away.
We're baffled because insofar as I can tell, there's only a one-liner being printed in Console.app: Exited with code: 255 (naturally running from the terminal doesn't help here because we can't reproduce the problem there; the app runs fine when launched in a terminal).
So the only thing we can figure is it's either something we're goofing up in our main.cpp, or something we've hosed in how I set up the dylibs/frameworks. It's also possible that it's something to do with the working directory not being set right, but to the best of my abilities, I believe we're doing it right (regardless of your current working directory; the app attempts to forcibly set said directory to be in the Resources folder - this was necessary to get the game to launch, but I don't know if we're doing it wrong). This feels like a somewhat awkward fit for stackoverflow, for which I apologize, since it's not a simple "paste this code and ask what's wrong" job. I have two ways for you to reproduce it; firstly we are an open-source project, and you can get our source code (complete with a mac project file and all dependencies included in the repo, set up and ready-to-go exactly as I've perhaps erroneously created them), at our github page. The one change you'll need to do is open a file at the root level, named master-config.cfg, and remove the // comments from it (so the engine knows you want to launch a simple demo game shipped with the engine).
Alternately, I have a stripped down (~15mb zipped) binary you can directly download and try to run, if that's sufficient to diagnose the problem.
As said before, we're open-source, so we welcome any pull-requests for fixes!
You need to write a minimal Cocoa wrapper so that OS X will not SIGKILL you for not launching properly. I will give you a pull request with that wrapper.
Related
the other day my little brother downloaded a game from somewhere, and as I caught him in the act of installing it, I noticed a little pop-up window in, like old windows graphics, popped up all sneaky and said "be now on auto start" or something close to that. So, is there any way I can find out what that was, where it is, or what it's doing, so I can see if it's a virus? thanks for your time and effort. the spell checker wont let me type v before "be on auto start"
There is no surefire way to locate an unknown .vbe file that is currently running. However, some detective work may be able to uncover its location. Try checking recently accessed files, running processes, and open network connections to see if any clues can be found.
Not a programming problem per se, but rather a programming environment problem that I have been unable to find a solution to.
The problem relates to Adobe's Extendscript Toolkit (both 3.5 and 4), but so far I haven't been able to solve the problem, so here I am...
The error I get has appeared more or less over night. I didn't experience this problem yesterday, nor this morning. But exactly WHAT has happened is beyond me. I have removed preferences, I have uninstalled, reinstalled, created a new user, restored old preferences from Time Machine and I'm now pretty much lost for options.
Basically, nothing works in ESTK anymore. Just opening ESTK and entering alert('Hello') won't work. Neither will $.writeln(). Everything running from within ESTK seems to give the same error;
Cannot execute script in target engine 'main'
With details:
Cannot execute script in target engine 'main'!
(#1116) Can't start debug session.
Below is a screenshot taken from the new user I created to test, same problem.
The "funny" thing is that all the scripts (InDesign CS5, still hanging on to it for reasons) still work perfectly in the applications' script panels. So there is nothing wrong with the scripts (heck, they haven't changed one bit, and still refuses to run in ESTK).
As mentioned, I've tried installing the ESTK CC (version 4) as well, but the very same problem occurs there. Which leads me to think the problem lies somewhere else, but I do not know where, and why.
So, if anyone can shed any light on this issue, at all, I would be very happy. Debugging is basically the only thing ESTK is good for in my book, but now that even that functionality is gone, I don't know how to efficiently debug the scripts which is kind of hampering the workflow.
For reference, I'm running InDesign CS5 (from the old Creative Suite) on a 2008 Mac Pro with 10.11.6 (El Capitan) installed. Well aware that it's pretty out of date, but that is beside the point here.
In the above mentioned forum, Adobe has published a stable workaround!You just have to correct a setting inside the estk application:
Open the file(Mac): “/Applications/Adobe ExtendScript Toolkit CC/ExtendScript Toolkit.app/Contents/SharedSupport/Required/cdic/11BTBackend.jsx”
Search for the value: 604800000 (line reads bt.timeout = 604800000)
Replace that value with 604800 and save
Quit ExtendScript Toolkit and relaunch.
I can confirm that it works.
From the adobe Forum :
"we have found a first workaround: just change your date to any date before 20-nov-2018"
https://forums.adobe.com/message/10761440#10761440
Seems like a date issue :(
I just published a quick update about this on the Adobe Tech Blog.
For the time being, if you dismiss the dialog, you can still run your script via ESTK and step through code as usual.
Alternatively, if you really want to avoid the dialogs, and you don’t mind setting your clock back, you can sidestep the issue by setting your system clock back to November 19, 2018 or before. On most systems, changing the system time can have unintended side effects, so this isn’t recommended unless you’re really certain about it.
I can't figure out why my calls to NSFileWrapper's addRegularFileWithContents:preferredFileName: is setting the files quarantine bit (as seen when using xattr -l on the file) when in the sandbox only. My app saves files in the document bundle so this I think is the method I need to use but the quarantine bit is driving me crazy.
Maybe this is a feature of some sort but my app also chmod's these files as executable and runs them as shell scripts using NSTask. However with the quarantine bit on I get errors from the bash shell (this has been well documented on stack overflow).
Has anyone else experienced this and do you know if these are bugs or features? The only way to work around it for now is to know the shell of the file in advance and not rely on the interpreter at the top of the file (i.e. #!/usr/bin/php) but this an annoying hack to work around a problem that shouldn't be.
I am having an unusual executable issue whenever I start up my Mac. The program is labelled "com.install4j.runtime.launcher". I assume it is related to this site but I am not sure if this is part of a system update or a third party application that requires this "4J launcher". Either way it has been bugging me for weeks now and I am not sure how to get rid of it!
Any advice would be greatly appreciated.
Okay I employed some help from a colleague to understand this. It turned out to be a simple and slightly embarrassing solution. Somewhere down the line I must have installed this 4J executable and for some reason it was set to open on start-up (not sure if this was a fault of my own or the Mac's).
For anyone else who has an issue with unwanted applications starting up upon log in, you can solve them fairly easily by hitting:
Apple icon (Top left) -> System Preferences -> Users & Groups -> Login Items
Then simply hit minus (-) to be rid of them! You may find some more unwanted applications on there like iTunes Helper or (in my instance) Flu.x which was being loaded 4 times... A nice way to speed up the mac on start up as well.
Hope this helps anyone who has similar problems.
I have a VB6 application that I provide support for. This application works on both Windows XP and Windows 7. Some users were migrated from Windows XP to Windows 7 using the User State Migration tool. These users now receive a generic "Application has crashed" Windows error message when they open certain screens (forms) in the application. My assumption is that there is a missing dll/ocx reference, but I'm having trouble tracking it down.
I've tried many/varied troubleshooting techniques:
Full uninstall and reinstall of my application
Manually re-registering all dll's and ocx's that I know are used
Running Process Monitor on a broken computer and a working computer to compare what dll's and ocx's are accessed. The answer might be here but even after filtering out most of the background noise the amount of data is overwhelming. At a minimum I reviewed all of the calls right before it crashes and all of the calls that were not successful. All of the non-successful calls match between working and non-working.
Installed the Windows Debugger Tools and captured a crash dump. Analyzed the crash dump with DebugDiag. DebugDiag says the exception is in msvbvm60.dll. I tried building a PDB file for my exe and loading it in DebugDiag to get more detail about where the exception is occuring but DebugDiag doesn't want to accept the PDB (might be doing something wrong here, but it just seems to ignore it. This same PDB file works fine when I do remote debugging, however.)
I recompiled my VB6 program without any optimizations in PCode. I've read online that sometimes building in PCode, while bad for performance, will tell you the real exception.
Used the above created PDB file to remote debug the VB6 application. The debugger says that the application crashes after the new window has been created, on a line that sets MousePointer = vbHourGlass... To me it seems unlikely that this is the real cause of the error. There are at least 20 other locations in the program where this same line is called and all work fine.
(Forgot about this one)
Used Dependency Walker and profiled the application on both a working and non-working computer. All errors found by dependency walker were the same between the two computers. There were no additional dependencies found on a working computer, and all missing dependencies on the non-working computer were also missing on the working one.
None of these actions changed my error message or showed me what the error is (unless it really is the mouse cursor issue)... There are no entries in the Windows Event Log related to the app crash.
The non-working and working computers all have the same base Windows 7 image, the only difference is whatever is being changed by USMT, which further convinces me that this is some kind of quirky configuration change or a missing dll/ocx or perhaps an unregistered dll/ocx.
Any ideas or thoughts on how I can track down the root cause of the issue would be greatly appreciated.
Update 1 - Response to questions
#MarkHall I have tried running it as admin, though not with UAC off. The application runs fine on a Windows 7 box as a non-admin with full UAC. Windows XP was 32-bit, Windows 7 is 64-bit, but again it works just fine on a like for like box where the user was not migrated from Windows XP.
#Beaner It's possible that it stores settings somewhere that have been corrupted, but the remote debugging leads me to think that it's more likely something else since it seems to die on a step related to the UI, which then makes me think it's probably a missing dll/ocx reference.
#Bob77 The application is installed into Program Files (x86). While many of the libraries do reside in the same folder, they are all registered.
Peter, often I've noticed that the debugger will indicate a line of code that is actually incorrect, depending on WHERE in the actual assembly language the fault occurs. You should look REAL close around your statement that sets the cursor to vbHourGlass. Your exception is PROBABLY happening BEFORE that line of code, but that line is what the debugger thinks is the actual faulted line of code.
Since you said it happens when a window OPENS, I'd look real close at any ocx's you may have referenced on the form, but perhaps NOT actually being used, or called. You might have one there that you don't intend to be there, that could be causing security issues, or something on Win7? Edit the .frm file by hand if you have to, and look at all the GUIDs the form references.
It is possible that one machine is using PER-USER registration, and the other is using PER-SYSTEM registration?? I don't know...
I would take a much closer look at the form that you are trying to open, and be VERY cautious of everything you are doing in the form load events, and so on. This sounds like it could be something as stupid as Windows Aero being enabled on one system, and not another, or some other sort of "Theme" setting that is throwing the VB Form Rendering routine into a hissyfit... Perhaps even something as stupid as a transparent color index in the icon you selected for that from?
If you are still developing this app, (or at least maintaining it), create an entirely NEW form, and re-create all the controls, etc, on the form (resist the temptation to copy/paste them from the old one...), and then see if THAT does the trick. Then, copy all the event code to the new form one event at a time, with at LEAST enough event code to make the form function, even if it's just a "dead form", that loads no data, or whatever the form is supposed to do. Check and debug after each change, and you WILL find it eventually. Of course, make sure you isolate one of the defunct systems to have a platform that you can duplicate the issue on, or then it's just guessing. I find that using something like Acronis w/ Universal Restore is a great option to then take the image file into a good HV, like VirtualBox, and then restore that image as a VM, so you can debug without interfering with your actual users. This sounds like a lot of work, but then again, so is re-writing an application that already exists, right? :)
Failing THAT... /* and */ are your friends!! (Well, we're dealing with VB, so ' would be your best friend! heh... But I'd start commenting out all the code on the form until that sucker opens. Then once it opens, start putting one line back at a time, and re-running it... That's called "VooDoo Debugging", but sometimes, you gotta do what you gotta do...
THANKS A LOT PETER! :) Now you got ME so involved in this, I feel like I'M the one debugging this sucker! Like if it was MY code I was trying to fix! :)
Let me know if any of this helps... I am actually quite interested in what you discover.