I'm trying to build the Mozilla Firefox code, and I ran upon this error:
I have asked the people at the Firefox development chatroom, and it seem no one has run into this problem before. I'm new to the open source development, and I don't have much experience in debugging a program like this before. I have looked at the log, and I don't where to start to figure out a problem like this.
Apparently this is a problem with Mozilla's specifically tooled version of clang 11 that is being pulled down through the bootstrap script. Dropping in an older clang version from Mozilla's CI allows one to get past this. Apparently it's linked specifically against Win 10 libraries so likely won't work on Win 7 or 8.
See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1699228
I've gotten past this with e.g. pulling down clang from https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/VzRmR7vqQmynv_6T14oguA/artifacts/public/build/clang.tar.bz2 as suggested by Mozilla employee glandium.
Related
Question
My app has some bugs that only occur on older macOS versions. How can I debug them?
Approaches
Below are all of the approaches I'm aware of.
Approach 1: Debug using Xcode
The idea is to just use Xcode to build and debug the project on the older macOS version.
Unfortunately the latest version of Xcode that is available on the old macOS cannot open my .xcodeproj file.
I have come accross 2 possible solutions:
1.2 Change Project Format
I have set the Project Format to be compatible with a very old version of Xcode (8.0) but that didn't help.
2.2. Change manually edit project files
You can manually edit the project file with a text editor and decrease the objectVersion to get the project to open. See this SO Answer.
This worked for me.
To get the project to compile on the old macOS version, I had to do a few more hacks:
Set objectVersion to 46
Comment out all code that uses unavailable APIs
Set 'minimumToolsVersion' in Interface Builder files your Xcode version
Set the Code Signing Identity to "Ad Hoc Code Sign" and disable hardened runtime on all targets
After these steps I could build and debug my app on the old macOS version! Some things didn't compile properly, but luckily, in my case, this was good enough to figure out all of the bugs that were occuring on older macOS versions!
Update:
I just tried to do the same thing with a Swift project (The other one was ObjC only) and it was so much work that I almost gave up on it. See the bottom of this post for more info.
Approach 2: Debugging from the command-line
The second idea is to use the lldb debugger directly from the command line on the old macOS. This works fine. But the problem here is that it will only show me assembly code. To debug in an efficient way you want to be able to step through source code line by line. This is achievable but it's complicated:
The following data needs to be present on the old macOS:
The app/executable itself
The source code used to build that executable
Some sort of 'debug data' that links machine instructions in the executable to lines in the the source code
You need to tell lldb how to link that data together
Here's an article on how to do this: https://medium.com/#maxraskin/background-1b4b6a9c65be
This approach is very promising but I gave up on it for now because the setup and debugging workflow sounds very slow and tedious and Approach 3 seemed to be much easier. However I can't get Approach 3 to work at all so far. I'll update this once I look into it more.
Sidenote about 'debug data'
I don't really understand some things about the 'debug data' mentioned above.
From what I gathered, this debug data normally comes in the so called DWARF data format. Debuggers usually extract this DWARF data directly from .o files. .o files are a byproduct when compiling C code (and code in other languages too?).
However for storing and transferring the DWARF data to other machines you can also store it in so called .dSym files.
Now what confuses me is what role does 'code stripping' play in all of this? Because code stripping is described on the internet to "remove debug data from the exectable". My question is - what kind of debug data is in the binaries when you don't strip them? Is it the same DWARF data from the .dSym and .o files which can be used to step through code line by line in a debugger? Or is it a subset of the DWARF data? Or is it something completely different?
Either way here's approach 3:
Approach 3: Remote debugging from the command-line
The lldb debugger has the built-in capability to connect to another machine remotely, then automatically upload the executable you want to debug to the remote machine, and then run and debug that executable.
In theory, this should also let the debugger automatically locate the source code files and the DWARF data - allowing you to step through source code line by line without any extra effort.
This would make the approach much more convenient than Approach 2! So I gave it a try, using the official tutorial.
There are many things that aren't explained in the official tutorial, and it was very hard to Google the various problems I ran into. Here are some things that I had to do which are not mentioned in the tutorial:
I downloaded the latest Xcode and got the debugserver and lldb command-line-tools that are buried deep inside that app bundle. I ran debugserver on the remote machine and connected to it using lldb on the local machine.
The official tutorial talks about using the lldb-server command-line-tool instead of debugserver. But I couldn't find lldb-server in the latest Xcode app bundle nor the latest Xcode Command Line Tools. (The ones that show up at /Library/Developer/CommandLineTools after using xcode-select --install). Older Xcode versions still contained both lldb-server and debugserver and from my testing they behave the same. Only the command line arguments they take are a little different. So I used debugserver instead of lldb-server.
Then I had to open a wifi hotspot on the remote machine using the Create Network... option in the menu bar, and then connect the local machine to that wifi hotspot.
On the remote machine I started the debugserver with this command debugserver 0.0.0.0:1234. 0.0.0.0 means "accept connections from any IP address" and 1234 means only accept connections on port '1234'
On the local machine I started lldb and inside the command prompt I used the following commands:
platform select remote-macosx
platform connect connect://<remote ip address>:1234
Replacing <Remote ip address> with the IP address of the remote machine which you can find under System Preferences > Network.
1234 means 'connect on port 1234'
I don't know where the structure of this URL comes from. I found it by accident
After this, lldb on local and debugserver on remote will both say they connected successfully.
target create <path to appbundle>
Replacing <path to appbundle> with the appropriate path
After this, lldb looks like it's uploading the files to the remote machine, but debugserver on the remote machine won't react. Not sure if that's normal.
process launch
This should launch the app on the remote machine, but instead it just give this cryptic error: error: attach failed: invalid host:port specification: '[<Remote ip address>]'. (Where <Remote ip address> is the actual IP address of the remote machine).
I tested this many times on different macOS versions. Local was always Ventura 13.0 and remote was 10.14 or 10.13. Both lldb and debugserver had version lldb-1400.0.38.13.
I don't know what else to try to make remote debugging using lldb work.
Sidenote about 'GDB'
I haven't looked into using the classic gdb debugger yet. Should I? I heard it's less buggy than lldb and I assume my problems with remote debugging are due to bugs in lldb. If it worked as advertised, remote debugging should be by far the easiest way to solve my problem.
I'll update this if I learn more about using GDB for remote debugging.
I'll be very grateful for any tips or clarifications! I will also update this post if I find out more, so this can hopefully be a useful resource for anyone trying to debug a Mac app on an older macOS version.
Update/Conclusion
Approach 1.2 worked for me!
(Approach 1.2 is getting the project to build in an older Xcode by manually editing project files.)
If you want to further explore the other approaches I've come across, here are my thoughts on how they compare with Approach 1.
Comparison to Approach 2
(Approach 2 is debugging from the command-line)
Pros of Approach 1
Much nicer debugging workflow - You can use the Xcode GUI instead of the command-line, and you won't have to copy over 3 different files to a new machine every time you want to test a change to your code.
Pros of Approach 2
You don't rely on hacking the project files which might not work for all situations. E.g. this might introduce new bugs in your compilation target that interfere with the bugs you actually want to debug.
Comparison to Approach 3
(Approach 3 is remote debugging from the command-line.)
Approach 3 is the holy grail. The debugging workflow would be very nice, no manually transferring files between computers like Approach 2, no weird brittle hacks like Approach 1.
Sadly I couldn't get Approach 3 to to work after days of trying, so I've given up on it now. If you have tips on how to make it work please do let me know!
Update 2
Approach 1.2 worked for my orginal project which was ObjC only. I've now tried to apply it to a Swift project and it's so much more work.
I had to spend hours rewriting code which was written for Swift 5.6 to compile under Swift 5.1 - it did work in the end but it took hours.
Unfortunately I haven't found a way to get a newer Swift version to compile under the older macOS, so I had to resort to this.
So if you're using Swift in your project, Approach 1.2 might be too much work to be feasible.
Update 3
Another possible solution might be using a Virtual Machine but I can't find any examples for how to do this on the internet.
I downloaded from official site and installed latest version of Gammu for windows.
The set-up runs just fine like any other exe I have ever installed.
Then, when I try to call the command as instructed in the official guide I get this message: (alternative)
I've tried anything but it's always the same.
All of the other similar "win32 not a valid application" questions are related to self-made applications or programming in general: I haven't found a similar problem related to gammu in the whole web, except for a very old case from seven years ago which suggest to downgrade, which of course I can't do.
any suggestion to this problem? anyone had a similar one
Okay, there seems to be problem with running apps built with recent Visual studio on Windows XP and 2003.
Fortunately there is a configuration to change this.
I've just committed this change to Gammu and the new binaries will soon build. They should be available for download here. It would be great if you can test them...
I don't know if anyone else has had this issue? Python 3.5.2, 3.5.5 and now agian using 3.6.0a3.Sudden unexplained python failure to start. Ide Idle Shows Fatal when trying to start when hours earlier all was fine. Have had this happen now three times. Details Below.
pythonw.exe
3.6.150.1013
585cd097
ucrtbase.DLL
10.0.10586.9
5642c5f8
40000015
0008469a
9a0
01d29a9be7dc282e
C:-----my path to it
C:\Windows\system32\ucrtbase.DLL
261c485f-068f-11e7-a405-c80aa953b2de
I will re install again and may have to revert back to earlier versions at 3.3. Any help in Preventing this or knowing what causes it would be great Thanks.
Don't try to use the development version, get 3.6.0. If python does not start, no python application can run, so IDLE is not relevant.
I strongly suspect your ucrtbase.dll is either corrupt or out-of-date. On my Win10 system, I have version 10.0.14393.0. I don't know if it should be the same on Win 7. Do you have Windows Update turned on?
In any case, other people have had problems with ucrtbase.dll. See for example, this tracker issue. It refers to this ucrtbase.dll update download page.
I get the following error Connection to the remote server was lost. Please check your Internet connection. (-1997)
Anybody know how I can get around this (I don't have problems with anything else)
macbook pro macos sierra
I had the same problem while trying to upgrade to v1.2.3 just now. The download failed just as it completed; I suspect something couldn't or wouldn't be written to disc. I tried downloading from within Capto four times before I gave up.
What I wound up doing was downloading the trial version of v1.2.3 (available at the Capto website) and running it. It recognized my license and automagically turned into the full version, so all was (and is) well. Capto also reports that it's now up to date.
I'm not sure what was wrong here, but I've never seen that error before. I also haven't been able to find out exactly what the error number indicates. It doesn't seem to have been on anybody's list before 2015, so maybe it's an El Capitan (and, probably, Sierra) thing.
UPDATE
This question seeks help with tooling - "how do I debug my problem." As I type this, there has been no answers. I did end up stumbling on the solution for the actual problem I was trying to solve and have provided the solution as an answer.
I still would be more than happy to hear any answers on the tooling question though, and if somebody comes up with a workable answer, I'll be more than happy to transfer the checkmark
Original Question
I initially opened an issue with YouCompleteMe https://github.com/Valloric/YouCompleteMe at https://github.com/Valloric/YouCompleteMe/issues/1345. It immediately got closed because there's no official support for Windows. Ok, fine.
I'm now asking the Stackoverflow community, hopefully there are people who are messing with YCM for Windows (there is a "unofficial YCM for Windows" page, so there MUST be SOMEBODY hacking on this thing).
Below is the original content of the issue that I opened.
If somebody actually has an answer that works, great! At this point, I'm looking more for procedures that I can use to run the YCM server under a debugger to see where exactly it's choking
I'm trying to get YCM to work on my Windows 7 machine. I have a few
other XP, Win7, Win8 machines that have no problems with YCM. I've
tried building the support stuff using MinGW, Visual Studio 2010, both
on the target machine as well as the other machines where I have YCM
working.
When I open a Python or C++ file, a message immediately appears that
YCM has crashed and I should restart with :YcmRestartServer. It
mentions that I should set g:ycm_server_keep_logfiles in order to see
the log messages. I have done that, but I still don't have any
logfiles and the "set g:ycm_server_keep_logfiles" message is still
appearing.
I also get ('Connection aborted.', error(10061, 'No connection could
be made because the target machine actively refused it'))
I looked in python\ycm\youcompleteme.py and saw that the "logfiles
deleted" message comes up because of an exception in trying to open
the file specified by self._server_stderr (IOError). Right now I'm
suspecting that this is because the server never actually gets far
enough in its startup sequence to actually create the stdout and
stderr files.
What are the steps that I could do to investigate why the server (?)
fails to start properly.
I also had a vague idea that there was a firewall rule blocking
connections, I looked through Windows Firewall, but didn't really see
anything that would point to localhost connections being blocked or
whatnot.
I'm okay with doing debugging, would appreciate advice on the
procedure that I would need to do in order to get Visual Studio 2010
to step into the server process and poke around stuff.
Oh, dunno if this factoid means anything, but I'm able to use
Rip-Rip's clang_complete without issues, but I would very much rather
use YCM.
I never really did get an answer or solution to the central question of "how do I debug YCM under Windows" but I did solve the underlying problem of why YCM wasn't working for me, so for posterity (and other fellow despairing YCM users who may end up here via Google)
For me, YCM immediately crashed and burned. I figured the problem out by seeing a Windows system that had been working fine for me start exhibiting the symptoms.
The change: I had installed Python 3.x and switched it to being the system preferred python (by messing with paths, what do you expect with Windows?).
As it turns out (duh), YCM depends on Python 2.x and falls over when it can't find any of the libraries that it was trying to open.
I started going down the path of trying to locate exactly what the files YCM was trying to access and provide them locally in the YCM directory, but after spending five minutes on it, I decided that I wanted something simpler.
Since I still wanted Python 3.x to be the 'system' version, I settled for manipulating the path WITHIN Vim, so I added this before the YCM load,
if (has('win32') || has('win64'))
let $PATH = 'C:\Python27;' . $PATH
endif
Hope that this saves somebody else some pain