freecad: Need help with segfault problem on F24

[Richard Shaw]

I'm pretty much stumped on a problem where freecad (really python-pivy)
segfaults on F24 but seems to run fine on F23 and I can't find any
substantive difference between any of the packages.

Strangely installing Coin3 from f23 on a f24 system seems to fix the
problem...

https://bugzilla.redhat.com/show_bug.cgi?id=1323159

Any pointers/help would be appreciated.

Thanks,
Richard

[Jerry James]

On Tue, Apr 19, 2016 at 8:50 PM, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  I'm pretty much stumped on a problem where freecad (really
> python-pivy)
>  segfaults on F24 but seems to run fine on F23 and I can't find any
>  substantive difference between any of the packages.
>
>  Strangely installing Coin3 from f23 on a f24 system seems to fix the
>  problem... 
Try building Coin3 with -fno-delete-null-pointer-checks in the CFLAGS.
I've had to add that to several packages on F24 to fix mysterious
segfaults.
-- 
Jerry James
http://www.jamezone.org/

[Przemek Klosowski]

On 04/19/2016 11:55 PM, Jerry James wrote:
>  On Tue, Apr 19, 2016 at 8:50 PM, Richard Shaw
> <hobbes1069(a)gmail.com&gt; wrote:
> > I'm pretty much stumped on a problem where freecad (really python-pivy)
> > segfaults on F24 but seems to run fine on F23 and I can't find any
> > substantive difference between any of the packages.
> >
> > Strangely installing Coin3 from f23 on a f24 system seems to fix the
> > problem...
>  Try building Coin3 with -fno-delete-null-pointer-checks in the CFLAGS.
>  I've had to add that to several packages on F24 to fix mysterious
>  segfaults. 
Yeah, but that means that we're just allowing silent null-pointer 
dereferencing. This can't be good: it probably just masks latent bugs: 
https://gcc.gnu.org/news/null.html

I understand that in principle, a program that segfaults due lack of the 
null-pointer test must be doing the actual null pointer dereference 
first. We should test for that and log bugs against such code----or is 
it too much work for too little benefit? Is there a way to automate 
that, e.g. via abrt?

[Jonathan Wakely]

On 20/04/16 09:51 -0400, Przemek Klosowski wrote:
> On 04/19/2016 11:55 PM, Jerry James wrote:
> >On Tue, Apr 19, 2016 at 8:50 PM, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
> >>I'm pretty much stumped on a problem where freecad (really python-pivy)
> >>segfaults on F24 but seems to run fine on F23 and I can't find any
> >>substantive difference between any of the packages.
> >>
> >>Strangely installing Coin3 from f23 on a f24 system seems to fix the
> >>problem...
> >Try building Coin3 with -fno-delete-null-pointer-checks in the CFLAGS.
> >I've had to add that to several packages on F24 to fix mysterious
> >segfaults.
> Yeah, but that means that we're just allowing silent null-pointer 
> dereferencing. This can't be good: it probably just masks latent bugs: 
> https://gcc.gnu.org/news/null.html 
Yes, but if the choices are to have code that dereferences null and
appears to work, or code that dereferences null and crashes, then
using the option as a temporary workaround is useful. Also, if the
option stops the crashes then it confirms that null dereferences are
indeed the cause of the crashes, not some other problem. That can
help find the real problem.

Building with -fsanitize=undefined should find the place where the
null dereference happens, so it can be fixed.

[Richard Shaw]

Well it turns out -fsanitize=undefined made no difference in this case...

Here's the stacktrace:

http://paste.fedoraproject.org/358119/46124321/

Thanks,
Richard

[Jonathan Wakely]

On 21/04/16 08:00 -0500, Richard Shaw wrote:
> Well it turns out -fsanitize=undefined made no difference in this
> case...
>
> Here's the stacktrace:
>
> http://paste.fedoraproject.org/358119/46124321/ 
allocator=0x0 is the problem there, that argument must be non-null.

It comes from:

    void operator delete(void * ptr) {
      SbHashEntry * entry = static_cast<SbHashEntry *>( ptr);
      cc_memalloc_deallocate(entry->memhandler, ptr);
    }

So the memhandler for that entry must be null.

[Richard Shaw]

On Fri, Apr 22, 2016 at 5:46 AM, Jonathan Wakely <jwakely(a)fedoraproject.org&gt;
wrote:

>  On 21/04/16 08:00 -0500, Richard Shaw wrote:
>
> > Well it turns out -fsanitize=undefined made no difference in this case...
> >
> > Here's the stacktrace:
> >
> > http://paste.fedoraproject.org/358119/46124321/
> >
>
>  allocator=0x0 is the problem there, that argument must be non-null.
>
>  It comes from:
>
>     void operator delete(void * ptr) {
>       SbHashEntry * entry = static_cast<SbHashEntry *>( ptr);
>       cc_memalloc_deallocate(entry->memhandler, ptr);
>     }
>
>  So the memhandler for that entry must be null. 

Any reason this would be OK on the f23 build but not f24? Newer version of
gcc with different default behavior?

Also, since that's pretty much greek to me, do you have a suggested fix?

Thanks,
Richard

[Richard Shaw]

Looks like Mamoru figured it out, thanks everyone for the help.

https://bugzilla.redhat.com/show_bug.cgi?id=1323159#c34

Thanks,
Richard

[Jonathan Wakely]

>  Looks like Mamoru figured it out, thanks everyone for the help.
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1323159#c34 
I'm curious what the fix is :-)

All the bugzilla says is that the memhandler is null, which was already apparent from the
stacktrace. I'll have a look when the patch lands in git.

[Richard Shaw]

On Fri, Apr 22, 2016 at 7:54 AM, Jonathan Wakely <jwakely(a)redhat.com&gt; wrote:

>  > Looks like Mamoru figured it out, thanks everyone for the help.
>  >
>  > https://bugzilla.redhat.com/show_bug.cgi?id=1323159#c34
>
>  I'm curious what the fix is :-)
>
>  All the bugzilla says is that the memhandler is null, which was already
>  apparent from the stacktrace. I'll have a look when the patch lands in git. 

Yeah, I was wondering why it's a problem in F24 but not F23 or before...
but the wait is over!

http://pkgs.fedoraproject.org/cgit/rpms/Coin3.git/commit/?id=ca89ec722794...

Thanks,
Richard

[Jonathan Wakely]

On 22/04/16 07:58 -0500, Richard Shaw wrote:
> On Fri, Apr 22, 2016 at 7:54 AM, Jonathan Wakely
> <jwakely(a)redhat.com&gt; wrote:
>
> > > Looks like Mamoru figured it out, thanks everyone for the help.
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1323159#c34
> >
> > I'm curious what the fix is :-)
> >
> > All the bugzilla says is that the memhandler is null, which was already
> > apparent from the stacktrace. I'll have a look when the patch lands in git.
>
>
> Yeah, I was wondering why it's a problem in F24 but not F23 or before...
> but the wait is over!
>
> http://pkgs.fedoraproject.org/cgit/rpms/Coin3.git/commit/?id=ca89ec722794...
It's a new optimization in F24's GCC 6, the "More aggressive
optimization of -flifetime-dse" change described at
https://gcc.gnu.org/gcc-6/porting_to.html

[Ralf Corsepius]

On 04/22/2016 02:58 PM, Richard Shaw wrote:
>  On Fri, Apr 22, 2016 at 7:54 AM, Jonathan Wakely
> <jwakely(a)redhat.com
>  <mailto:[e-mail]>> wrote:
>
>      > Looks like Mamoru figured it out, thanks everyone for the help.
>      >
>      >https://bugzilla.redhat.com/show_bug.cgi?id=1323159#c34
>
>      I'm curious what the fix is :-)
>
>      All the bugzilla says is that the memhandler is null, which was
>      already apparent from the stacktrace. I'll have a look when the
>      patch lands in git.
>
>
>  Yeah, I was wondering why it's a problem in F24 but not F23 or before...
>  but the wait is over! 
How about
* filing a BZ against Coin3 such that the Coin3 maintainer (me) gets 
informed and has a chance to reproduced the issue?

* filing and proposing a patch in advance, instead of rushing out patch?

> http://pkgs.fedoraproject.org/cgit/rpms/Coin3.git/commit/?id=ca89ec722794...
Ralf

[Richard Shaw]

On Fri, Apr 22, 2016 at 9:34 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  How about
>  * filing a BZ against Coin3 such that the Coin3 maintainer (me) gets
>  informed and has a chance to reproduced the issue?
>
>  * filing and proposing a patch in advance, instead of rushing out patch? 

Apologies, of course you are right. I just got so wrapped up into trying to
figure out what the problem is.

The fix (if appropriate) should also probably be sent to the upstream issue
tracker.

Thanks,
Richard

[Richard Shaw]

On Fri, Apr 22, 2016 at 9:34 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:

>  How about
>  * filing a BZ against Coin3 such that the Coin3 maintainer (me) gets
>  informed and has a chance to reproduced the issue?
>  
Done.

https://bugzilla.redhat.com/show_bug.cgi?id=1153551

Thanks,
Richard

[Richard Shaw]

On Mon, Apr 25, 2016 at 3:15 PM, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:

>  On Fri, Apr 22, 2016 at 9:34 AM, Ralf Corsepius
> <rc040203(a)freenet.de&gt;
>  wrote:
>
> >
> > How about
> > * filing a BZ against Coin3 such that the Coin3 maintainer (me) gets
> > informed and has a chance to reproduced the issue?
> >
>
>  Done.
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1153551
>  
Have you had any luck reproducing the issue and/or verifying the validity
of the fix?

I sincerely hope you are not purposefully ignoring this bug report as I
have already apologized for my overzealousness and ignoring it only harms
users.

Thanks,
Richard

[Przemek Klosowski]

On 05/03/2016 02:16 PM, Richard Shaw wrote:
>  On Mon, Apr 25, 2016 at 3:15 PM, Richard Shaw
> <hobbes1069(a)gmail.com 
>  <mailto:[e-mail]>> wrote:
>
>      On Fri, Apr 22, 2016 at 9:34 AM, Ralf Corsepius
>      <rc040203(a)freenet.de <mailto:[e-mail]>> wrote:
>
>
>          How about
>          * filing a BZ against Coin3 such that the Coin3 maintainer
>          (me) gets informed and has a chance to reproduced the issue?
>
>
>      Done.
>
>      https://bugzilla.redhat.com/show_bug.cgi?id=1153551
>
>
>  Have you had any luck reproducing the issue and/or verifying the 
>  validity of the fix? 
I am sligtly confused here (so what else is new :).***Bug
1153551* 
<https://bugzilla.redhat.com/show_bug.cgi?id=1153551> seems to be 
brasero's "Cannot burn files from network drive".
What am I missing?

Also, you comment ( 
https://bugzilla.redhat.com/show_bug.cgi?id=1323159#c50 ) that the fix 
was pushed to f24 stable, but I don't see it in the update stream (my 
repolist is F24 fedora/updates/updates-testing). Should I be looking 
somewhere else? if so, can you send a link to the test RPM?

[Richard Shaw]

On Tue, May 3, 2016 at 2:50 PM, Przemek Klosowski <
przemek.klosowski(a)nist.gov&gt; wrote:

>  I am sligtly confused here (so what else is new :). *Bug 1153551*
>  <https://bugzilla.redhat.com/show_bug.cgi?id=1153551>  seems to be
>  brasero's "Cannot burn files from network drive".
>  What am I missing?
>  
I was task switching between several bugs that day and must have had the
wrong one for copy/paste, the correct bug is:

https://bugzilla.redhat.com/show_bug.cgi?id=1329814


Also, you comment ( https://bugzilla.redhat.com/show_bug.cgi?id=1323159#c50
>  ) that the fix was pushed to f24 stable, but I don't see it in
> the update
>  stream (my repolist is F24 fedora/updates/updates-testing). Should I be
>  looking somewhere else? if so, can you send a link to the test RPM?
>  
No, the package that's causing the segfault (Coin3) is not part of the
update but it causes a segfault in python-pivy regardless of whether you're
running the old 0.15 package or new 0.16 package so I went ahead and pushed
to stable so I could update f22/23, otherwise the version in f23/23 would
be newer than that's in f24.

Thanks,
Richard

[Przemek Klosowski]

On 05/03/2016 03:54 PM, Richard Shaw wrote:
>  the package that's causing the segfault (Coin3) is not part of
> the 
>  update but it causes a segfault in python-pivy regardless of whether 
>  you're running the old 0.15 package or new 0.16 package so I went 
>  ahead and pushed to stable so I could update f22/23, otherwise the 
>  version in f23/23 would be newer than that's in f24. 
On my two fully updated
systems I have the following versions of Coin3:
__________  __V_  __R___  Built     Installed
Fedora 24: 3.1.3 16.fc24 Feb  3   Apr 2
Fedora 23: 3.1.3 11.fc23 Jul 29   Dec 22

so the new version didn't make it out yet. Would it help if we installed 
a version from koji/bodhi somewhere? if so, where is it?

[Richard Shaw]

On Tue, May 3, 2016 at 3:17 PM, Przemek Klosowski <
przemek.klosowski(a)nist.gov&gt; wrote:

>  On 05/03/2016 03:54 PM, Richard Shaw wrote:
>
>  the package that's causing the segfault (Coin3) is not part of the update
>  but it causes a segfault in python-pivy regardless of whether you're
>  running the old 0.15 package or new 0.16 package so I went ahead and pushed
>  to stable so I could update f22/23, otherwise the version in f23/23 would
>  be newer than that's in f24.
>
>  On my two fully updated systems I have the following versions of Coin3:
>  __________  __V_  __R___  Built     Installed
>  Fedora 24: 3.1.3 16.fc24 Feb  3   Apr 2
>  Fedora 23: 3.1.3 11.fc23 Jul 29   Dec 22
>
>  so the new version didn't make it out yet. Would it help if we installed a
>  version from koji/bodhi somewhere? if so, where is it?
>  
Hence the BZ on Coin3. I'm technically a co-maintainer but Ralph didn't
appreciate my quick fix without including him so I stopped after performing
a build for Rawhide and I'm currently waiting for him to review the patch
used for Rawhide and apply it to f24 assuming it's appropriate.

Thanks,
Richard

[Jonathan Wakely]

On 22/04/16 07:36 -0500, Richard Shaw wrote:
> On Fri, Apr 22, 2016 at 5:46 AM, Jonathan Wakely
> <jwakely(a)fedoraproject.org&gt;
> wrote:
>
> > On 21/04/16 08:00 -0500, Richard Shaw wrote:
> >
> >> Well it turns out -fsanitize=undefined made no difference in this case...
> >>
> >> Here's the stacktrace:
> >>
> >> http://paste.fedoraproject.org/358119/46124321/
> >>
> >
> > allocator=0x0 is the problem there, that argument must be non-null.
> >
> > It comes from:
> >
> >    void operator delete(void * ptr) {
> >      SbHashEntry * entry = static_cast<SbHashEntry *>( ptr);
> >      cc_memalloc_deallocate(entry->memhandler, ptr);
> >    }
> >
> > So the memhandler for that entry must be null.
>
>
> Any reason this would be OK on the f23 build but not f24? Newer version of
> gcc with different default behavior? 
No idea, sorry.

> Also, since that's pretty much greek to me, do you have a
> suggested fix? 
Nope, I didn't look any further.