Raspberry Pi 3B+ compile attempt appears to hang

Having trouble installing or compiling FreeCAD? Get help here.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Dakidd
Posts: 23
Joined: Wed Jul 21, 2021 11:01 pm

Re: Raspberry Pi 3B+ compile attempt appears to hang

Post by Dakidd »

adrianinsaval wrote: Fri Nov 26, 2021 8:03 pm
Dakidd wrote: Fri Nov 26, 2021 6:59 pm Hi adrianinsaval -
Your commentary is noted, and while I can't say "You're wrong", the fact that after the apt update, a "cat /etc/os-release" shows me that I'm running buster is fairly convincing evidence I do indeed have "the latest", whatever it actually is.
yes but this is not due to the apt update, that only updates the package database
I'll have to take your word for it - *nix isn't my "native language", so to speak.
adrianinsaval wrote: Fri Nov 26, 2021 8:03 pm
Dakidd wrote: Fri Nov 26, 2021 6:59 pm And the bad news is, after just under an hour, I'm looking at the same thing I have been on previous attempts:
[ 9%] Building CXX object src/App/CMakeFiles/FreeCADApp.dir/Document.cpp.o
maybe you are running out of ram? do you have a swap file/partition? can you monitor the ram usage?
It's entirely possible, but my limited *nix skills don't include knowing how to check that concept.
Dakidd
Posts: 23
Joined: Wed Jul 21, 2021 11:01 pm

Re: Raspberry Pi 3B+ compile attempt appears to hang

Post by Dakidd »

-alex- wrote: Fri Nov 26, 2021 10:04 pm Quote -alex-
by -alex- » Fri Nov 26, 2021 2:04 pm
BTW you should keep Buster, do not upgrade to Bullseye for now IMO. I'm attempting to compile FC master on RPI4 with RPIOS Bullseye, with some success but there is an issue with Draft workbench. I will open a dedicated thread about this issue.
As @adrianinsaval said please open a task manager or any tool to check the RAM consuption when compiling reach 9% then report.
Are you using Buster 32B? To get system informations, please
Frankly, I wouldn't know buster from bullseye from Bullwinkle the moose. All I know for certain is what I see when I do a "cat /etc/os-release" command, and I've already posted that info. I'm just running with what I'm handed (mostly). I'm minimally functional in *nix-land these days. Used to know my way around SCO Unix 30-odd years ago, but I'm primarily a Mac person these days. I can, if I must, operate in shell-land, but for the most part, I stick to Finder-based operations.

Will look into this "neofetch" thing you speak of.

No idea where the .img that installs my base package comes from - I imaged the SD card I use by downloading the Raspberry Pi imaging program from their website, and the OctoPrint/OctoPi package is one of the options available in it. Where it actually gets what it writes to the card is a complete and total mystery to me. For all I know, it could be reaching into my left ear and putting whatever it finds there on the card.
Dakidd
Posts: 23
Joined: Wed Jul 21, 2021 11:01 pm

Re: Raspberry Pi 3B+ compile attempt appears to hang

Post by Dakidd »

After ripping out the idiotic and totally pointless ascii-art Raspberry (remind me to hit the man-page (if it has one) and look for a way to permanently kill that obscenity - if it's like most *nix stuff, there's gotta be a way...) here's what's left from running this "neofetch" package you pointed me at:

OS: Raspbian GNU/Linux 10 (buster) armv7l
Host: Raspberry Pi 3 Model B Plus Rev 1.3
Kernel: 5.10.63-v7+
Uptime: 1 day, 5 hours, 55 mins
Packages: 1327 (dpkg)
Shell: bash 5.0.3
Theme: Adwaita [GTK3]
Icons: Adwaita [GTK3]
Terminal: /dev/pts/1
CPU: BCM2835 (4) @ 1.400GHz
Memory: 91MiB / 871MiB
Dakidd
Posts: 23
Joined: Wed Jul 21, 2021 11:01 pm

Re: Raspberry Pi 3B+ compile attempt appears to hang

Post by Dakidd »

OK, NOW we're getting somewhere...

Went hunting for how to turn on or otherwise make use of virtual memory - My google-fu passed the trial, and I ended up making a 10 gig swap file. After a reboot to make absolutely sure the swap I'd created was "visible" to the system, I decided to try just cd-ing into $HOME/freecad-build/ and going for a "make -j1", with the idea that it would pick up wherever it left off. It did, zipping through the targets I've seen go by before in rapid-fire "Built target InsertNameHere" succession before slowing down enough for me to actually read the screen at - Yep, you guessed it - 9% done, and trying to digest the Document.cpp file that's been the killer until now.

Also found "top" and "htop" (I knew those, years ago in my SCO days, but had ENTIRELY forgotten them) - Fired up htop in another window, and holy crap, but the compiler *ABSOLUTELY HAMMERS* whatever processor it can get its hands on, doesn't it?! Full 100% usage for extended periods, and I suspect that if I hadn't put the "-j1" on the make command, it would have been trying to grab another core for even more. Almost as soon as I punched return on the make command, my #4 core spun up to 100% and sat there pegged, and memory started vanishing in gigantic wads - Was up past 80% in less than 30 seconds, then apparently swapping kicked in - Before it finished with "Document.cpp" and moved on to the next file, the indicator that I assume means "swap space currently in use" was up over the 75% mark. When it finished with "Document.cpp", that dropped to nil, and what I assume is the "memory currently in use" indicator dropped back to under 10%, and hasn't gotten much above 50% for any of the files handled since.

It appears that the killer is something about Document.cpp that wants absolute GOBS of memory during the compile phase - the build is proceeding, about 2 dozen files beyond "Document.cpp" now, currently claiming to be 10% done.

You guys may not have directly cured my problem, but you definitely managed to point me in the direction to make some progress. For that much, even if nothing else, I gotta thank you big-big. I was starting to get some pretty impressive lumps on my skull from beating my head against this particular wall!

Whether the result is going to be functional at any level is another question - one that's that's obviously going to have to wait for however long it takes the compile to finish. At least I'm not dead in the water wondering why nothing useful is happening...
Dakidd
Posts: 23
Joined: Wed Jul 21, 2021 11:01 pm

Re: Raspberry Pi 3B+ compile attempt appears to hang

Post by Dakidd »

Woke up to find that the compile had completed this morning - no reported errors. YAY!

That's the good news...
Still working in the terminal window/ssh session I'm using to access the RPi (using the "-Y" option to tell it I might be wanting to use X11), I tried to fire up FC. The results from that follow (Obviously, the ascii-art doesn't come through worth diddly in a non-monospace font - looks fine in my terminal window, though):

<begin paste>
pi@octopi:~ $ ./freecad-build/bin/FreeCAD
FreeCAD 0.20, Libs: 0.20R26489 (Git)
© Juergen Riegel, Werner Mayer, Yorik van Havre and others 2001-2021
FreeCAD is free and open-source software licensed under the terms of LGPL2+ license.
FreeCAD wouldn't be possible without FreeCAD community.
##### #### ### ####
# # # # # #
# ## #### #### # # # # #
#### # # # # # # # ##### # #
# # #### #### # # # # #
# # # # # # # # # ## ## ##
# # #### #### ### # # #### ## ## ##

connect failed: No such file or directory
<end paste>

At this point, the terminal window I'm working in "goes dead", and an XQuartz (Mac's version of an X11 terminal) window opens (a window more than twice the width of my monitor, BTW... Fortunately, I can drag it around enough to get to the resize widget and shrink it down to fit. Is that just a bad configuartion of XQuartz, or something FreeCAD is doing? Can't tell yet), where I see the splash screen with modules and such loading, then the usual FreeCAD start window. So far, so good, give or take some (semi-)minor questions...

First off, what's trying to connect, to where, and why, and why is it failing? Tell me this isn't a case of "FC Phone Home"? That kind of on-the-sneak behavior is a bit spooky. Assuming it's trying to connect to some local resource, which is the first thing that occurs to me because of the "No such file or directory", no big deal. If it's trying to connect to something out on the 'net, it shouldn't be having any difficulties - the Pi is configured to hook into the same WiFi router the Mac I'm making this post from uses to get there, and like my Mac, is fully able to connect to the 'net - That's how I got the source code and dependencies onto it in the first place. Either way, no clue what its looking for or why it's failing to find it.

I also note that I apparently have the 0.20 source code, rather than the 0.19 I thought I was getting. Not a major problem, but not quite what I expected.

That's the good news.

The bad news is that as soon as I hit the "Create new..." button on the start screen, or go up to the file menu and try to do a "New", the result is the same: KABOOM! The XQuartz window vanishes, and the terminal window I used to start FC "reactivates", and this is what I see in it, picking up starting with the last line of the last paste (No, there aren't two "connect failed..." lines - just the one):

<start second paste>
connect failed: No such file or directory
Coin warning in cc_glglue_instance(): Error when setting up the GL context. This can happen if there is no current context, or if the context has been set up incorrectly.
Program received signal SIGSEGV, Segmentation fault.
#0 /lib/arm-linux-gnueabihf/libc.so.6(__default_sa_restorer+0) [0x714a0110]
pi@octopi:~ $
<end second paste>

This seems to be a FreeCAD-specific problem with Coin, since every bing/google result I looked at came back to posts here on the forum with BASICALLY the same complaint, though I haven't spotted a definitive answer in any of the threads where it appears.

Suggestions on how to proceed? If I were working in XCode (The Mac dev environment where most of my coding/debugging/etc goes on) and got a crash like this, I'd have quite a bit more information available, including a stack trace, and various other stuff that would at least give me an indication of how to proceed. Over here in Raspberry-land, I don't even have a sensible "What do I do next???" question to pose, let alone any indication of what actually went ker-blooey. My best guess right now is to try GDB and see what can be seen tracing through the run, but that's going to take some learning on my part to make it happen - I've been spoiled by the Mac's IDE taking care of the "down on the silicon" stuff these past few years.
User avatar
-alex-
Veteran
Posts: 1856
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: Raspberry Pi 3B+ compile attempt appears to hang

Post by -alex- »

You've selected the good strategy, that's great! :)
The segfault issue is a known issue as you know now. Not fixed yet. Except if you use RPIOS64B beta.
But with octopi buster 32B the issue occurs as well following what you've expérience.
I have alsmost no skills in programming, so my help here is very limited.
But because you're using RPI3B+ with gpu broadcom VC4, I would advise to go to raspi-config menu then switch from legacy driver to Fake kms then to full kms (faulty I guess).
IIRC lagacy driver should be ok (tested on raspian Jessy or Stretch few years ago), but slower as well....
About ssh X11 access, HDMI management and so on, I have no strong opinion neither expérience.
Dakidd
Posts: 23
Joined: Wed Jul 21, 2021 11:01 pm

Re: Raspberry Pi 3B+ compile attempt appears to hang

Post by Dakidd »

-alex- wrote: Sun Nov 28, 2021 2:04 pm The segfault issue is a known issue as you know now. Not fixed yet. Except if you use RPIOS64B beta.
But with octopi buster 32B the issue occurs as well following what you've expérience.
The reading I've been doing since yesterday *SUGGESTS* that Buster IS 64 bit, but nothing explicitly comes out and says it is - only hints in that direction. Which I find odd.
-alex- wrote: Sun Nov 28, 2021 2:04 pm But because you're using RPI3B+ with gpu broadcom VC4, I would advise to go to raspi-config menu then switch from legacy driver to Fake kms then to full kms (faulty I guess).
IIRC lagacy driver should be ok (tested on raspian Jessy or Stretch few years ago), but slower as well....
Stumbled across nearly the same advice on a website calling itself "Raspberry Pi Geek", and have done that. I'm showing 41% through cloning the RealThunder branch source code currently, so I haven't yet tried to see if the crash happens with the new GL settings. Once the clone is completed, I'll give the 0.20 build I've got another try, and see if diddling the GL settings makes any difference. If not (and even if it does) I'll be trying to get the RealThunder branch to compile - I like the way that one looks and "feels" better on the Mac, and have had less problems than under the 0.19 build when trying to accomplish the tasks I've been doing with it, so I'm probably better off sticking with it. Now that I know I've got the skills, toolchain, and dependencies on the Pi to at least build (even if not fix the problems encountered so far) the main branch, I'm a lot more comfy with trying to mess with "non-standard" builds like RealThunder's.

I'll probably keep posting updates on my progress here. Maybe it'll help "the next guy", whoever that might be, to get a working FreeCAD on his RPi 3B+ too. I'm thinking it would be pretty cool to midwife a new, working version into being on a platform that can't currently use it. :)
User avatar
-alex-
Veteran
Posts: 1856
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: Raspberry Pi 3B+ compile attempt appears to hang

Post by -alex- »

Dakidd wrote: Sun Nov 28, 2021 7:01 pm The reading I've been doing since yesterday *SUGGESTS* that Buster IS 64 bit, but nothing explicitly comes out and says it is - only hints in that direction. Which I find odd.
More information about FC compiling and RPI4 here and here issue #4083
ATM RPIOS64B(beta) Buster gives the best results to compile FC with Py3/Qt5 without segfault issue.
That said it is also possible to compile successfully FC with Py2/Qt4 on RPIOS 32B Buster, or Py3/Qt4 as a workaround.
RPI3 seems to crash the same way, but I'm notre sure. Waiting for your report.

Edit: disambiguous naming of RPIOS64B (beta) Buster disto
Last edited by -alex- on Wed Dec 01, 2021 5:16 pm, edited 1 time in total.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Raspberry Pi 3B+ compile attempt appears to hang

Post by adrianinsaval »

Dakidd wrote: Fri Nov 26, 2021 10:48 pm OS: Raspbian GNU/Linux 10 (buster) armv7l
armv7 is 32bit, debian (the distro this is based on) is one of the distros with the most architectures supported so there is buster arm x86 64bit 32bit etc etc
Dakidd
Posts: 23
Joined: Wed Jul 21, 2021 11:01 pm

Re: Raspberry Pi 3B+ compile attempt appears to hang

Post by Dakidd »

adrianinsaval wrote: Mon Nov 29, 2021 12:52 pm
Dakidd wrote: Fri Nov 26, 2021 10:48 pm OS: Raspbian GNU/Linux 10 (buster) armv7l
armv7 is 32bit, debian (the distro this is based on) is one of the distros with the most architectures supported so there is buster arm x86 64bit 32bit etc etc
That's useful info - thanks. That's probably why I was seeing hints that Buster was 64 bit, rather than being able to find an explicit "Buster Is/Is Not 64 bit" statement - Makes sense that on a 64 bit processor, it would run as 64 bit, but if it's only a 32bit processor, it can't possibly run in 64 bit mode.
Post Reply