Description of problem: after the last update (0.14 -> 0.15) it crashes changing to most modes i noticed the last update installed Coin, and the assert/abort is also coin related FreeCAD: SoBase.cpp:190: SoBase::SoBase(): Assertion `(SoBase::classTypeId != SoType::badType()) && "An SoBase-derived class was attempted instantiated *before* Coin initialization. (Have you perhaps placed an SoBase-derived instance (e.g. a scene graph node) in non-heap memory?) See SoBase class documentation for more info."' failed. Version-Release number of selected component: freecad-0.15-1.fc21 Additional info: reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: /usr/bin/FreeCAD crash_function: SoType::isDerivedFrom executable: /usr/lib/freecad/bin/FreeCAD kernel: 3.19.3-200.fc21.i686 runlevel: N 5 type: CCpp uid: 1000 var_log_messages: [System Logs]:\n-- Logs begin at Sun 2014-09-28 14:10:46 PDT, end at Thu 2015-05-14 08:34:48 PDT. -- Truncated backtrace: Thread no. 1 (10 frames) #5 SoType::isDerivedFrom at SoType.cpp:730 #6 SoBase::isOfType at SoBase.cpp:608 #7 coin_internal_safe_cast<SoGlobalField*, SoBase> at ../../src/SbBasicP.h:77 #8 coin_safe_cast<SoGlobalField*> at ../../src/SbBasicP.h:88 #9 coin_internal_assert_cast<SoGlobalField*, SoBase> at ../../src/SbBasicP.h:115 #10 coin_assert_cast<SoGlobalField*> at ../../src/SbBasicP.h:129 #11 SoGlobalField::getGlobalFieldContainer at SoGlobalField.cpp:206 #12 SoDB::getGlobalField at SoDB.cpp:905 #13 SoDBP::updateRealTimeFieldCB at SoDBP.cpp:155 #14 SoSensor::trigger at SoSensor.cpp:187
Created attachment 1025489 [details] File: backtrace
Created attachment 1025490 [details] File: cgroup
Created attachment 1025491 [details] File: core_backtrace
Created attachment 1025492 [details] File: dso_list
Created attachment 1025493 [details] File: environ
Created attachment 1025494 [details] File: limits
Created attachment 1025495 [details] File: maps
Created attachment 1025496 [details] File: open_fds
Created attachment 1025497 [details] File: proc_pid_status
I may have to get some help figuring this one out. FreeCAD 0.15 does require Coin3 so going back to Coin2 isn't an option. One problem is that python-pivy is currently being build with Coin2 so that *might* be causing the problem. Also python-pivy requires SoQt which freecad doesn't require anymore but it's also built against Coin2.
Another user experienced a similar problem: Attempted to load dxf file (1.5MB) created by TeighaFileConverter from dwg file (ACAD 14) reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: /usr/bin/FreeCAD /home/john/tmp/map23028.dxf crash_function: SoType::isDerivedFrom executable: /usr/lib64/freecad/bin/FreeCAD kernel: 3.19.7-200.fc21.x86_64 package: freecad-0.15-1.fc21 reason: FreeCAD killed by SIGABRT runlevel: N 5 type: CCpp uid: 1000
*** Bug 1221853 has been marked as a duplicate of this bug. ***
*** Bug 1222020 has been marked as a duplicate of this bug. ***
Fix is SoQt and Pivy (python-pivy) need to be rebuilt against Coin3 OR I'll have to downgrade the package to 0.14.
The rebuild would be a much preferred solution. Some of the new features would be really nice to have. Also this thread (http://forum.freecadweb.org/viewtopic.php?f=4&t=9213) suggests using the development version of Coin3D (Coin4).
Agreed, but I'm not the package maintainer for SoQt or SIMVoleon both of which would need to be rebuilt against Coin3 before Pivy. I'm going to try coin4 (which is a fork). If I can make it parallel installable to Coin2/3 then I'll submit a review request. Which there was a faster fix.
Will those packages be built against Coin3 in fedora 22? If they will be then the simple solution would be to build FreeCAD-0.15 for fedora 22 and revert to FreeCAD-0.14 for fedora 21. My concern with using Coin4 (being a fork) is that it may become incompatible with Coin3 and break FreeCAD again. You could also argue that if FreeCAD upstream is using Coin3 then the fedora packages should do the same otherwise other, inconsistent, bugs may appear just for fedora. Regards, Neil Darlow
I didn't inspect the prebuild Ubuntu packages, but Coin4 was actually a suggestion of one of the authors (Yorik van Havre in a thread mentioned above, quote: "The fedora build info might indeed be a bit outdated. IIRC the last time someone edited it, only Coin2 was available. If you have access to Coin3, indeed use it! Or even Coin4 if possible.").And later in the same thread: "There are known FreeCAD bugs with coin3 .... the diameter does not display in Draft dimensions....so coin4 would seem a logical choice...if there are no other reasons not to use coin4 on your system."
Regardless, the main problem is if you want any module that uses Pivy (Drafting and Arch I believe) that it still needs to be built with Coin3/4 which also requires that SoQt and SIMVoleon be rebuilt against the same version and I don't maintain either of those packages.
corsepiu, can you please help with that?
Hi, Can someone please confirm that: yum downgrade freecad freecad-data smesh is sufficient to revert to 0.14 and that it is not necessary to downgrade the OCE-* packages which were also recently updated? Regards, Neil Darlow
(In reply to Jiri Kastner from comment #20) > corsepiu, can you please help with that? Well, I don't get the problem. If I understand correctly, freecad-0.15 requires Coin3+all Coin-based packages (SoQt, SIMVoleon, Pivy) built against Coin3, right? So far this has happened on Fedora >= 22, but not on Fedora < 22 and is unlikely to happen there.
Yes, as I mentioned in my email, I would have liked to update through f21 and although updates like this mid-release are discouraged, I think the freecad update is important enough to go through the trouble especially if the dependency chain is as short as it appears to be. At this point is anything actively using coin2?
(In reply to Richard Shaw from comment #23) > Yes, as I mentioned in my email, I would have liked to update through f21 > and although updates like this mid-release are discouraged, Correct. There should not be any API/ABI breakages during the life-time of a release. > I think the > freecad update is important enough Well, I understand freecad is important to you and is your baby in Fedora, but I think FreeCAD is just an arbitrary package amongst the 10000+ other packages fedora consists of. Actually, I think, Coin and FreeCAD are unimportant enough to justify an exception from the rules otherwise applied in Fedora - You would not propose such a step for glibc or GCC, won't you? ;) > At this point is anything actively using coin2? The problem is not Coin2 or Coin3, the problem is with SoQt, Pivy and SIMVoleon. That said, I am not aware about any package using SoQt, Pivy and SIMVoleon (but FreeCAD) in Fedora. Coin2 and Coin3 can co-exist and are installable in parallel, but SoQt and SIMVoleon can't (I haven't checked Pivy), because Coin2/Coin3 compiled variants would carry the same SONAMEs, PATHs etc. This also would mean, rebuilding these packages against Coin3 would be undetectable at the user-level and would break any packages user may have installed locally.
So, aside from the Coin4 is better than Coin3 argument, fedora 22 should have a working FreeCAD 0.15. The question just remains as to what should be done for fedora 21. While it might be nice to have FreeCAD 0.15 for fedora 21 there is the question of whether there is sufficient time left before the release of fedora 22 to justify the effort involved in doing so. Additionally, the update recently pushed to fedora 21 is clearly broken and that needs to be addressed for users wishing to retain fedora 21. My personal opinion is that this update should be rolled-back. Those wishing to have FreeCAD 0.15 should be OK with updating to fedora 22 and, in all likelihood, will do so to take advantage of other package updates. Regards, Neil Darlow
regarding fedora i'm fine with such solution, but epel6/7 is another cup of coffee as they are 'long term support fedoras'. and as epel user (both el6 and el7) i would like to have there fresh freecad.
(In reply to Ralf Corsepius from comment #24) > (In reply to Richard Shaw from comment #23) > Actually, I think, Coin and FreeCAD are unimportant enough to justify an > exception from the rules otherwise applied in Fedora - You would not propose > such a step for glibc or GCC, won't you? ;) I think the opposite argument is true, they aren't important enough to to worry about enforcing the rule... > > At this point is anything actively using coin2? > The problem is not Coin2 or Coin3, the problem is with SoQt, Pivy and > SIMVoleon. > > That said, I am not aware about any package using SoQt, Pivy and SIMVoleon > (but FreeCAD) in Fedora. The irony is that FreeCAD doesn't even use them directly, only through Pivy. > Coin2 and Coin3 can co-exist and are installable in parallel, but SoQt and > SIMVoleon can't (I haven't checked Pivy), because Coin2/Coin3 compiled > variants would carry the same SONAMEs, PATHs etc. This also would mean, > rebuilding these packages against Coin3 would be undetectable at the > user-level and would break any packages user may have installed locally. Since Pivy is a python module without soversion, I don't see any way for a Pivy+Coin2 and Pive+Coin3 package to coexist. (In reply to Jiri Kastner from comment #26) > regarding fedora i'm fine with such solution, but epel6/7 is another cup of > coffee as they are 'long term support fedoras'. > and as epel user (both el6 and el7) i would like to have there fresh freecad. I've worked hard to keep many packages in EPEL but when the dependencies change (as they did in FreeCAD between 0.14->0.15) and they aren't in RHEL or EPEL, it gets to the point where it's not worth it. Now that we have COPR, I think that's the best route to go. Even there though if you need a newer package than what's supplied in RHEL or EPEL you can still have problems.
Ok, I've bumped the Epoch to be able to downgrade the package. Doing rawhide builds now (still 0.15, but with Epoch bumped to make sure the NEVR is greater in rawhide)
My thoughts are to get FreeCAD working in F22 and RHE but forget about F21. That seems to be the issue with all the dependent packages. I am lucky enough to just be learning FreeCAD but many of the tutorials are geared for 0.15. I can still wait for F22. I can keep using 0.15 for most of what I do for now.
freecad-0.15-4.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/freecad-0.15-4.fc22
freecad-0.14-7.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/freecad-0.14-7.fc21
freecad-0.14-7.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/freecad-0.14-7.fc20
Package freecad-0.14-7.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing freecad-0.14-7.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-8925/freecad-0.14-7.fc21 then log in and leave karma (feedback).
V0.15 Dies on opening or import of .dxf polyline files. Downgrading to V0.14-7 as per above comment fixes this iss, but it isn;t then V0.15.
It's not currently possible to have 0.15 on Fedora 21 due to SoQt and Pivy still be linked against Coin2 instead of Coin3. I might recommend you give things a week or two to calm down but the F22 release includes 0.15.
*** Bug 1227162 has been marked as a duplicate of this bug. ***
Checking the bug with FreeCAD developers at their bug tracking system, they said it's a pivy problem. I could reproduce it easily going to FreeCAD Python console and trying "from pivy import coin". Crashes. pivy on F21 is 5.0.8. I installed 5.0.10 from F23 and noy FreeCAD works. Here's the bug ticket at FreeCAD: http://www.freecadweb.org/tracker/view.php?id=2143
I wish I still had 0.15 on my system to test. I installed the python-pivy from rawhide (f23) and now I would like to test freecad again, is the 0.15 rpm available from some place for testing?
freecad-0.14-7.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
freecad-0.14-7.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
freecad-0.15-4.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.