Release app segfault issues
Archives Forums/Linux Discussion/Release app segfault issues
| ||
| As of late I have been seeing segfault issues with release builds using later distributions of Linux. I suspected that the problem was down to the way later GCC versions applied optimisations to generated code and the few test I've tried seem to confirm it. But here's the weird part. A convoluted build process seems to fix it. It shouldn't if it was down to optimisations. This was tested on Debian 8.6 as it has the problem with creating release builds with the github master and the construction scripts. But making a custom script that works like this: 1) Make a bin directory and copy the supplied github binaries bmk and bcc for Linux over to it. 2) Build only the debug modules. 3) Build bmk and bcc as debug builds, but do not use the option to output the binaries back into the bin directory. 4) Delete the original bmk and bcc, before replacing them with the debug builds. 5) Flush out the old object (.o) and static (.a) library files, before rebuilding modules as release versions. find . \( -name ".o" -name ".a" \) -type f -delete 6) Build bmk and bcc as release builds, but do not use the option to output the binaries back into the bin directory. 7) Delete the debug versions of bmk and bcc, before replacing them with the new release builds. 8) May not be necessary, but flush out the modules again and this time rebuild all the modules. Any thoughts on this issue? |
| ||
| Any reason for "4)" and "7)" needing that "delete ... before" ? Potential Cache invalidation ? (just remembering the "demoapp"-segfault-issue which is only happening for 50% of the executions). So in short your approach is: - build a debug variant of the toolchain binaries - use the debug versions to build the toolchain binaries in release mode (instead of the originally provided release-build of the toolchain binaries) ? In that case it should not need steps "5)" and "8)" as an enforced module rebuild rebuilds regardless of the current module compilation state and existing "a's and o's". Or hmm, only if there is no "link to all existing .o-files in a directory" - which I doubt (avoid mixing release/debug/mt). With Brucey's BMK (BMK-NG) shouldn't this gcc optimization can get deactivated via "custom.bmk" default #compiler optimisation setccopt optimization -O2 bye Ron |
| ||
| I was also getting seg fault issues with 64bit linux, that's why I put most of my projects on hold with bmx. same setup I would assume. |
| ||
| Any reason for "4)" and "7)" needing that "delete ... before" ? Potential Cache invalidation ?" More a feeling that somehow an an old build bcc is getting mixed with a new bmk build or visa-versa. So building both together first and then getting rid of the old out of the bin directory before moving the new to replace them. In that case it should not need steps "5) A precautionary measure. As the old object files would still be there, so I though clean them out and start afresh.So if it turns out that what I did with Debian 8.6 works on other distributions. Then it would look like that the supplied versions of bcc and bmk need rebuilding to work of any new version of GCC. If not; then its going to be a real problem in the future. With Brucey's BMK (BMK-NG) shouldn't this gcc optimization can get deactivated via "custom.bmk" Brucey's bcc and bmk are not affcted, but you still need a working vanilla bcc and bmk to build Brucey's stuff from scratch. All you need is the debug build of vanilla bcc and bmk to get Brucey's basic tool chain started. @RustyKristi: It's not just 64 bit that is affected. The 32 bit Debian seg faulted as well. Ubuntu 16.04 uses GCC version 5.4.0 Debian 8.6 uses GCC 4.9.2 Ubuntu 14.04 uses GCC 4.8.4 and should work out of the box. Think It may be an idea to go over it with sanitise. |
| ||
| Re BMK-NG You know you could use BMK-NG together with vanilla BCC (if not, you know it now :-))? So I was talking about using "BCC" and "BMK-NG" to build the "new BCC release build" skipping the "debug-build-step". Download a prebuild linux BMK-NG, a vanilla BCC, the vanilla sources (docmod, brl,pub ...) and you should be able to start compiling the new bcc from the sources (bmk-ng handles compiling the modules if needed). bye Ron |
| ||
| Actually I have no problems running with 32bit and that's emulated. yes I'm using Ubuntu btw 14.04 and 4.8.4 is the perfect version with vanilla. Maybe try downgrading to 4.8.4? |
   |