Re: MacPorts vs. Apple compiler issues, Handle
On 20/3/2024 03:23, Riccardo Mottola wrote: Hi, Joshua Root wrote: And this is where it happened. Since this is not a full debug build, there is no line number information, but you at least know which method is doing the bad memory access. But it should be a debug build. Well a build with debug symbols (not a firefox-style debug which adds also a lot of debug code). I add: ac_add_options --disable-strip and this helps on Linux usually. If the binary was stripped, you wouldn't see any names, just addresses. To see line numbers, you have to build with -g, and the DWARF information has to be available at runtime, by default in the build directory in .dSYM bundles. Still, the nsWindowWatcher class gave me a clue and I found a couple of Firefox patches to import which initialized parameters, checked them, etc and now the error changed to> 0 XUL 0x0001035f5c44 JS::Rooted::registerWithRootLists(js::RootLists&) + 20 1 ??? 0x7ffeecb477f0 0 + 140732869670896 this is bad, since it is inside the JS engine. Also the JS engine works on other system when compiled with modern clang and gcc! Also here I don't have a class name which maps directly to a file which I can easily inspect. Looks like its defined in js/public/RootingAPI.h ? - Josh
Re: MacPorts vs. Apple compiler issues, Handle
Well, “involved” perhaps was too much of a statement, I meant we communicated on the matter and it was/is work-in-progress to make it work on PowerPC. We got White Star (Palemoon) building on ppc not long ago btw, but it does not yet run. P. S. I should change my Gmail settings, otherwise I’m unrecognizable :) @barracuda156 On Mar 20, 2024 at 00:30 +0800, Riccardo Mottola , wrote: > Hi, > > Sergio Had wrote: > > Could you refer me to the beginning of this discussion please? > it started on the Mac Users mailing list, you can find in the archives! > > > > > > I am also involved in AF project:) > > Oh, I am curious, how? > I am essentially the only active developer currently, except Roy who > does its windows fork. > > Riccardo
Re: MacPorts vs. Apple compiler issues, Handle
Hi, Sergio Had wrote: Could you refer me to the beginning of this discussion please? it started on the Mac Users mailing list, you can find in the archives! I am also involved in AF project:) Oh, I am curious, how? I am essentially the only active developer currently, except Roy who does its windows fork. Riccardo
Re: MacPorts vs. Apple compiler issues, Handle
Hi, Joshua Root wrote: (Moving to macports-dev as it is a better fit for this topic.) indeed, it is a development issue, although well, not for a MacPorts package (yet?) but use of MP development tools. Issues that only appear at higher optimisation levels also often involve undefined behaviour. Right.. I reduced optimization to O1 with no change, I have strange issues compiling with O0! Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 XUL 0x00010f5468e1 nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, char const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, nsIDocShellLoadInfo*, mozIDOMWindowProxy**) + 273 And this is where it happened. Since this is not a full debug build, there is no line number information, but you at least know which method is doing the bad memory access. But it should be a debug build. Well a build with debug symbols (not a firefox-style debug which adds also a lot of debug code). I add: ac_add_options --disable-strip and this helps on Linux usually. Still, the nsWindowWatcher class gave me a clue and I found a couple of Firefox patches to import which initialized parameters, checked them, etc and now the error changed to> 0 XUL 0x0001035f5c44 JS::Rooted::registerWithRootLists(js::RootLists&) + 20 1 ??? 0x7ffeecb477f0 0 + 140732869670896 this is bad, since it is inside the JS engine. Also the JS engine works on other system when compiled with modern clang and gcc! Also here I don't have a class name which maps directly to a file which I can easily inspect. I will try clang 7 & 8, just so. Riccardo
Re: MacPorts vs. Apple compiler issues, Handle
Could you refer me to the beginning of this discussion please? I am also involved in AF project :) > On Mar 19, 2024, at 10:11 AM, Joshua Root wrote: > > (Moving to macports-dev as it is a better fit for this topic.) > > On 18/3/2024 22:50, Riccardo Mottola wrote: >> I will do another compilation reducing the optimization level. GCC has an >> issue where beyond gcc6 certain optimizations need to be disabled, or AF >> crashes. > > Issues that only appear at higher optimisation levels also often involve > undefined behaviour. > >> Exception Type:EXC_BAD_ACCESS (SIGSEGV) >> Exception Codes: KERN_INVALID_ADDRESS at 0x7ffe2007 > > So here is what happened: SIGSEGV means the program tried to access memory > that it should not have. The page was not mapped or had the wrong permissions > for what it was trying to do. The memory address that it attempted to access > is also shown. > >> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >> 0 XUL 0x00010f5468e1 >> nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, char >> const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, >> nsIDocShellLoadInfo*, mozIDOMWindowProxy**) + 273 > > And this is where it happened. Since this is not a full debug build, there is > no line number information, but you at least know which method is doing the > bad memory access. > > - Josh
Re: MacPorts vs. Apple compiler issues, Handle
(Moving to macports-dev as it is a better fit for this topic.) On 18/3/2024 22:50, Riccardo Mottola wrote: I will do another compilation reducing the optimization level. GCC has an issue where beyond gcc6 certain optimizations need to be disabled, or AF crashes. Issues that only appear at higher optimisation levels also often involve undefined behaviour. Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x7ffe2007 So here is what happened: SIGSEGV means the program tried to access memory that it should not have. The page was not mapped or had the wrong permissions for what it was trying to do. The memory address that it attempted to access is also shown. Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 XUL 0x00010f5468e1 nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, char const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, nsIDocShellLoadInfo*, mozIDOMWindowProxy**) + 273 And this is where it happened. Since this is not a full debug build, there is no line number information, but you at least know which method is doing the bad memory access. - Josh
