Opened 13 months ago

Last modified 2 months ago

#68452 new defect

kdelibs4 @4.14.3_110 +debug+docs+osxkeychain: onto2vocabularyclass segfaults during build

Reported by: cooljeanius (Eric Gallager) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.8.1
Keywords: Cc: barracuda156, StanSanderson, ShadSterling (Shad Sterling), Dave-Allured (Dave Allured), Squid4572 (Squid), RJVB (René Bertin), Lev-GitHub, TheLastLovemark, t0mbertin
Port: kdelibs4 soprano raptor2

Description

Split off from #67881. I reattempted building even while dirty here just to get the errors grouped together in a single part of the terminal output; I'll make sure to clean before attaching the full log:

/bin/sh: line 1: 53004 Segmentation fault: 11  /opt/local/bin/onto2vocabularyclass --name NDO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/nepomuk/ndo.trig
make[2]: *** [nepomuk/ndo.h] Error 139
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
/Library/Developer/CommandLineTools/usr/bin/make  -f kross/test/CMakeFiles/krosstest.dir/build.make kross/test/CMakeFiles/krosstest.dir/build
/bin/sh: line 1: 53002 Segmentation fault: 11  /opt/local/bin/onto2vocabularyclass --name NEXIF --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/nie/nexif.trig
make[2]: *** [nepomuk/nexif.h] Error 139
make[2]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
make[2]: Nothing to be done for `kross/test/CMakeFiles/krosstest.dir/build'.
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
[ 52%] Built target kunittestmodrunner
[ 53%] Built target kconf_update
/bin/sh: line 1: 53007 Abort trap: 6           /opt/local/bin/onto2vocabularyclass --name NFO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/nie/nfo.trig
make[2]: *** [nepomuk/nfo.h] Error 134
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
/Library/Developer/CommandLineTools/usr/bin/make  -f kross/kjs/CMakeFiles/krosskjs.dir/build.make kross/kjs/CMakeFiles/krosskjs.dir/build
make[2]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
make[2]: Nothing to be done for `kross/kjs/CMakeFiles/krosskjs.dir/build'.
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
/bin/sh: line 1: 53011 Segmentation fault: 11  /opt/local/bin/onto2vocabularyclass --name NMM --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/nie/nmm.trig
make[2]: *** [nepomuk/nmm.h] Error 139
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
/Library/Developer/CommandLineTools/usr/bin/make  -f kross/qts/CMakeFiles/krossqtsplugin.dir/build.make kross/qts/CMakeFiles/krossqtsplugin.dir/build
/bin/sh: line 1: 53009 Segmentation fault: 11  /opt/local/bin/onto2vocabularyclass --name NIE --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/nie/nie.trig
make[2]: *** [nepomuk/nie.h] Error 139
make[2]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
make[2]: Nothing to be done for `kross/qts/CMakeFiles/krossqtsplugin.dir/build'.
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
[ 53%] Built target kross
/bin/sh: line 1: 53017 Abort trap: 6           /opt/local/bin/onto2vocabularyclass --name NUAO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/nepomuk/nuao.trig
make[2]: *** [nepomuk/nuao.h] Error 134
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
/Library/Developer/CommandLineTools/usr/bin/make  -f kross/qts/CMakeFiles/krossqts.dir/build.make kross/qts/CMakeFiles/krossqts.dir/build
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
/Library/Developer/CommandLineTools/usr/bin/make  -f experimental/libkdeclarative/CMakeFiles/kdeclarativetest.dir/build.make experimental/libkdeclarative/CMakeFiles/kdeclarativetest.dir/build
/bin/sh: line 1: 53015 Segmentation fault: 11  /opt/local/bin/onto2vocabularyclass --name NMO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/nie/nmo.trig
make[2]: *** [nepomuk/nmo.h] Error 139
make[2]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
make[2]: Nothing to be done for `kross/qts/CMakeFiles/krossqts.dir/build'.
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
/bin/sh: line 1: 53019 Segmentation fault: 11  /opt/local/bin/onto2vocabularyclass --name PIMO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/pimo/pimo.trig
make[2]: *** [nepomuk/pimo.h] Error 139
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
make[1]: *** [nepomuk/CMakeFiles/nepomuk.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make[2]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
make[2]: Nothing to be done for `experimental/libkdeclarative/CMakeFiles/kdeclarativetest.dir/build'.
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
[ 53%] Built target krosstest
[ 53%] Built target krosskjs
[ 54%] Built target krossqtsplugin
[ 54%] Built target kdeclarativetest
[ 54%] Built target krossqts
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
make: *** [all] Error 2
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build" && /usr/bin/make -j16 -w all VERBOSE=ON 
Exit code: 2
Error: Failed to build kdelibs4: command execution failed
DEBUG: Error code: CHILDSTATUS 48332 2
DEBUG: Backtrace: command execution failed
    while executing
"system {*}$notty {*}$callback {*}$nice $fullcmdstring"
    invoked from within
"command_exec -callback portprogress::target_progress_callback build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/main.log for details.
DEBUG: Rebuilding port kdelibs4 finished with status 1
DEBUG: rev-upgrade failed: Error rebuilding kdelibs4
    while executing
"error "Error rebuilding $portname""
    (procedure "revupgrade_scanandrebuild" line 460)
    invoked from within
"revupgrade_scanandrebuild broken_port_counts $opts"
Error: rev-upgrade failed: Error rebuilding kdelibs4

I'm on Big Sur with Xcode 13. Some additional info:

$ port provides /opt/local/bin/onto2vocabularyclass
/opt/local/bin/onto2vocabularyclass is provided by: soprano
$ port installed soprano
The following ports are currently installed:
  soprano @2.9.4_7+debug+docs (active)

So this is probably actually an issue with soprano instead, and the kdelibs4 build process just exposed it...

Attachments (7)

kdelibs4-main.log.bz2 (221.9 KB) - added by cooljeanius (Eric Gallager) 13 months ago.
(bzipped) main.log for kdelibs4, after cleaning and retrying (and with trace mode on this time around, as well)
kdelibs main.log.zip (725.3 KB) - added by StanSanderson 9 months ago.
kdelibs4-no_variants-no_segfault-main.log.tgz (632.4 KB) - added by ShadSterling (Shad Sterling) 9 months ago.
onto2vocabularyclass_2024-01-29-032032-4_EricGallagersMacBookPro.crash (52.1 KB) - added by cooljeanius (Eric Gallager) 9 months ago.
my latest crash report for onto2vocabularyclass
diagnostics.zip (49.7 KB) - added by StanSanderson 9 months ago.
onto2vocabularyclass_2024-04-12-162602_sergey-fedorovs-power-mac-g5.crash (96.9 KB) - added by barracuda156 7 months ago.
Yep, looks like it is Raptor
raptor2_err.log (224.3 KB) - added by cooljeanius (Eric Gallager) 7 months ago.
stderr output from building raptor2 with GCC's static analyzer enabled

Download all attachments as: .zip

Change History (56)

Changed 13 months ago by cooljeanius (Eric Gallager)

Attachment: kdelibs4-main.log.bz2 added

(bzipped) main.log for kdelibs4, after cleaning and retrying (and with trace mode on this time around, as well)

comment:1 Changed 10 months ago by barracuda156

Got the same error, apparently, on PowerPC:

:info:build [ 52%] Generating qrc_kjscmd.cxx
:info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build/kjsembed/kjscmd && /opt/local/libexec/qt4/bin/rcc -name kjscmd -o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build/kjsembed/kjscmd/qrc_kjscmd.cxx /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/kdelibs-4.14.3/kjsembed/kjscmd/kjscmd.qrc
:info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build && /opt/local/bin/cmake -E cmake_depends "Unix Makefiles" /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/kdelibs-4.14.3 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/kdelibs-4.14.3/kjsembed/kjscmd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build/kjsembed/kjscmd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build/kjsembed/kjscmd/CMakeFiles/kjscmd.dir/DependInfo.cmake --color=
:info:build /bin/sh: line 1: 11131 Segmentation fault      /opt/local/bin/onto2vocabularyclass --name TMO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/pimo/tmo.trig
:info:build make[2]: *** [nepomuk/tmo.h] Error 139
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
:info:build make[1]: *** [nepomuk/CMakeFiles/nepomuk.dir/all] Error 2
:info:build make[1]: *** Waiting for unfinished jobs....

comment:2 Changed 10 months ago by barracuda156

Cc: barracuda156 added

comment:3 Changed 9 months ago by cooljeanius (Eric Gallager)

note that this blocks the upgrading of pretty much all other KDE ports; in particular I need to upgrade kde4-runtime and kmix currently.

comment:4 Changed 9 months ago by StanSanderson

Cc: StanSanderson added

comment:5 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: ShadSterling added

Has duplicate #69231.

comment:6 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)

Somebody please attach the crash log.

Unfortunately it looks like the soprano project has been archived by its developers so it is not being developed anymore and it is not possible to report bugs against it anymore.

Changed 9 months ago by StanSanderson

Attachment: kdelibs main.log.zip added

comment:7 Changed 9 months ago by ShadSterling (Shad Sterling)

I'm not sure what happened here, I tried building with all variants disabled, and it still failed, but without any segfault, or any clear reason I can see in the log. Is #69231 maybe not a duplicate? Or did my build of kde4-runtime with no variants trigger a build of kdelibs4 with these variants?

Changed 9 months ago by ShadSterling (Shad Sterling)

comment:8 Changed 9 months ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:9 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: Squid4572 added

I see two more main.log files have been attached, but they both only tell us what we already know: that onto2vocabularyclass crashed. What we now need to see is the log that macOS generated in /Library/Logs/DiagnosticReports about why that crash happened.

Has duplicate #69233.

Changed 9 months ago by cooljeanius (Eric Gallager)

my latest crash report for onto2vocabularyclass

comment:10 Changed 9 months ago by cooljeanius (Eric Gallager)

Just attached my latest crash report for onto2vocabularyclass; it looks like the issue is in libraptor2.0.dylib, which means that this might actually be an issue with the raptor2 port:

$ port provides /opt/local/lib/libraptor2.0.dylib
/opt/local/lib/libraptor2.0.dylib is provided by: raptor2
$ port installed raptor2
The following ports are currently installed:
  raptor2 @2.0.16_1 (active)
Last edited 9 months ago by cooljeanius (Eric Gallager) (previous) (diff)

Changed 9 months ago by StanSanderson

Attachment: diagnostics.zip added

comment:11 Changed 9 months ago by StanSanderson

Another attempt- diagnostics.zip. Hope it helps

comment:12 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)

Has duplicate #69324.

comment:13 Changed 8 months ago by barracuda156

With soprano disabled, it installed normally for me with no other changes:

36-64% port -v installed kdelibs4
The following ports are currently installed:
  kdelibs4 @4.14.3_111 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2024-03-22T04:00:58+0800'

comment:14 Changed 8 months ago by barracuda156

It also segfaults with other ports:

[  9%] Linking CXX executable nepomukserver.app/Contents/MacOS/nepomukserver
cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_nepomuk-core/nepomuk-core/work/build/server && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/nepomukserver.dir/link.txt --verbose=ON
/usr/bin/g++-4.2 -pipe -Os -DNDEBUG -fno-common -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual  -Werror=return-type -fvisibility-inlines-hidden -arch ppc -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-headerpad_max_install_names CMakeFiles/nepomukserver.dir/nepomukserver_dummy.cpp.o -o nepomukserver.app/Contents/MacOS/nepomukserver  -Wl,-rpath,/opt/local/lib ../lib/libkdeinit4_nepomukserver.dylib /opt/local/lib/libkdeui.5.14.3.dylib /opt/local/lib/libkdecore.5.14.3.dylib /opt/local/libexec/qt4/lib/libQtDBus.dylib /opt/local/libexec/qt4/lib/libQtCore.dylib -framework Carbon /opt/local/libexec/qt4/lib/libQtGui.dylib /opt/local/libexec/qt4/lib/libQtSvg.dylib /opt/local/lib/libsoprano.dylib /opt/local/lib/libsopranoserver.dylib 
cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_nepomuk-core/nepomuk-core/work/build/server && /opt/local/bin/cmake -D_filename=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_nepomuk-core/nepomuk-core/work/build/server/nepomukserver.app/Contents/MacOS/nepomukserver.shell -D_library_path_variable=DYLD_LIBRARY_PATH -D_ld_library_path="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_nepomuk-core/nepomuk-core/work/build/lib/./:/opt/local/lib" -D_executable=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_nepomuk-core/nepomuk-core/work/build/server/nepomukserver.app/Contents/MacOS/nepomukserver -P /opt/local/share/apps/cmake/modules/kde4_exec_via_sh.cmake
/bin/sh: line 1: 85855 Segmentation fault      /opt/local/bin/onto2vocabularyclass --name NDO --encoding trig --namespace Nepomuk2::Vocabulary --export-module nepomuk /opt/local/share/ontology/nepomuk/ndo.trig
make[2]: *** [libnepomukcore/ndo.h] Error 139
/bin/sh: line 1: 85935 Segmentation fault      /opt/local/bin/onto2vocabularyclass --name NEXIF --encoding trig --namespace Nepomuk2::Vocabulary --export-module nepomuk /opt/local/share/ontology/nie/nexif.trig
make[2]: *** [libnepomukcore/nexif.h] Error 139
/bin/sh: line 1: 85835 Segmentation fault      /opt/local/bin/onto2vocabularyclass --name NCO --encoding trig --namespace Nepomuk2::Vocabulary --export-module nepomuk /opt/local/share/ontology/nie/nco.trig
make[2]: *** [libnepomukcore/nco.h] Error 139
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_nepomuk-core/nepomuk-core/work/build'
make[1]: *** [libnepomukcore/CMakeFiles/nepomukcore.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

comment:15 Changed 8 months ago by barracuda156

Gentoo folks apparently blame alike errors on Java:

https://bugs.gentoo.org/283288

https://bugs.gentoo.org/284475

comment:16 Changed 7 months ago by cooljeanius (Eric Gallager)

Port: raptor2 added

comment:17 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

I see nothing java-related in the crash reports attached here.

comment:18 in reply to:  17 Changed 7 months ago by barracuda156

Replying to ryandesign:

I see nothing java-related in the crash reports attached here.

I have no idea what fails here and why, but it would be great to have it fixed somehow.

Did anyone try to revert to an earlier version of soprano?

UPD. Okay, I did now. Installed soprano 2.9.3, and got the same failure with kdelibs4:

/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build'
:info:build /bin/sh: line 1: 73240 Segmentation fault      /opt/local/bin/onto2vocabularyclass --name TMO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/pimo/tmo.trig
:info:build make[2]: *** [nepomuk/tmo.h] Error 139

So either it got broken already back then, or the problem is elsewhere.

Last edited 7 months ago by barracuda156 (previous) (diff)

Changed 7 months ago by barracuda156

Yep, looks like it is Raptor

comment:19 Changed 7 months ago by barracuda156

Opened an issue with Raptor upstream, maybe they could help us here: https://github.com/dajobe/raptor/issues/66

comment:20 Changed 7 months ago by kencu (Ken)

opening an upstream issue regarding a 2007 powerpc build of 10.6 running a heavily-patched qt4 installation should be interesting :)

if you folks would like to sort these things out, you are going to have to learn basic debugging skills.

Figure out how to build the necessary software with optimizations turned off and debugging code left in. Leave the source intact at the end of the build using “-k”.

run the crashing software under a debugger, lldb for any recent os, gdb for the archeological os versions.

watch it crash. generate a full backtrace with line numbers and source code.

Last edited 7 months ago by kencu (Ken) (previous) (diff)

comment:21 Changed 7 months ago by cooljeanius (Eric Gallager)

The backtrace included in the crash report already attached ought to be enough, IMO; I think I may have already found the null pointer dereference within it just by looking at it, and have commented to point it out in the linked upstream bug report.

comment:22 Changed 7 months ago by kencu (Ken)

It's not that much more to do a proper job, IMHO, especially when it comes to the decades-old systems.

Last edited 7 months ago by kencu (Ken) (previous) (diff)

comment:23 in reply to:  21 ; Changed 7 months ago by barracuda156

Replying to cooljeanius:

The backtrace included in the crash report already attached ought to be enough, IMO; I think I may have already found the null pointer dereference within it just by looking at it, and have commented to point it out in the linked upstream bug report.

Unfortunately, it does not seem to fix the issue. I have rebuilt raptor2 with your change, rebuilt soprano, and got the same segfault with kdelibs4 :(

comment:24 in reply to:  23 Changed 7 months ago by cooljeanius (Eric Gallager)

Replying to barracuda156:

Replying to cooljeanius:

The backtrace included in the crash report already attached ought to be enough, IMO; I think I may have already found the null pointer dereference within it just by looking at it, and have commented to point it out in the linked upstream bug report.

Unfortunately, it does not seem to fix the issue. I have rebuilt raptor2 with your change, rebuilt soprano, and got the same segfault with kdelibs4 :(

Well, I also tried turning on GCC's static analysis flags, so maybe one of the potential null dereferences flagged there is the one to blame... I'll attach output from that next...

Changed 7 months ago by cooljeanius (Eric Gallager)

Attachment: raptor2_err.log added

stderr output from building raptor2 with GCC's static analyzer enabled

comment:25 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

I don't know how to read that log, except the end, which is suspicious, isn't it?

dyld: Library not loaded: @rpath/libicui18n.73.dylib
  Referenced from: /Users/ericgallager/Documents/GitHub/raptor2/src/.libs/libraptor2.0.dylib
  Reason: image not found

Is that a MacPorts icu library? If so, why is it using @rpath?

comment:26 in reply to:  25 Changed 7 months ago by cooljeanius (Eric Gallager)

Replying to ryandesign:

I don't know how to read that log, except the end, which is suspicious, isn't it?

dyld: Library not loaded: @rpath/libicui18n.73.dylib
  Referenced from: /Users/ericgallager/Documents/GitHub/raptor2/src/.libs/libraptor2.0.dylib
  Reason: image not found

Is that a MacPorts icu library? If so, why is it using @rpath?

That's from me trying to build manually with extra warnings turned on to see if they can help me find where the code causing the segfault is coming from; I don't think the @rpath part at the end is relevant to that...

comment:27 Changed 7 months ago by kencu (Ken)

the failing command is this one:

/opt/local/bin/onto2vocabularyclass --name TMO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/pimo/tmo.trig

to run that, go into the build first:

cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build

and then run the command, to watch it segfault.

Now you want to run that under the debugger. So go into the folder again:

cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build

and this time, run it under lldb, like this:

lldb /opt/local/bin/onto2vocabularyclass

and after lldb opens, type this into the lldb prompt (basically - "run" and then the arguments):

run --name TMO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/pimo/tmo.trig

then it will crash again, but inside the debugger. Then you can press "bt" to generate the proper backtrace.

However, you can't see as much as you would like to see, because some of the software involved has been installed with debugging symbols stripped out and heavy optimization turned on. In particular, raptor2 is such a beast.

So we will rebuild raptor2 with debugging symbols left in and with optimizations turned off. I looked over raptor2, and the easiest way to do that is to use the debug 1.0 PortGroup.

To do that, first uninstall raptor2:

sudo port -f uninstall raptor2

and then edit the raptor2 Portfile to add PortGroup debug 1.0 near the top.

Now reinstall raptor2, but leave the source code behind after the installation to allow you to trace it. You do that like this:

sudo port -v -s -k install raptor2 +debug

OK, now we have raptor2 installed with everything as we want it.

Now, we go back to our lldb line:

cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_kde_kdelibs4/kdelibs4/work/build
lldb /opt/local/bin/onto2vocabularyclass

and then:

run --name TMO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/pimo/tmo.trig

and you can now see a WHOLE lot more of what was going on when onto2vocabularyclass crashed.

To really get a good look around, put lldb into GUI mode by typing:

gui

you can trace up and down the source code of raptor2, you can go into the various frames, and see what the variables were set to when the subroutines were called.

You might spot the issue doing that pretty quickly, or you might find out that the error is not in raptor2 itself, but in another piece of code, like perhaps soprano. Perhaps soprano will need to be reinstalled with the raptor2 treatment to see everything that is going on with soprano.

presumably, there is a NULL variable being sent to a routine that is not expecting it to be NULL, it would seem.

Last edited 7 months ago by kencu (Ken) (previous) (diff)

comment:28 Changed 7 months ago by kencu (Ken)

another interesting thing to read about and try is to set a breakpoint a bit earlier than the crashing point in the program, and then once the debugger gets to the breakpoint, you can step through the lines of code until the crash happens.

that can be helpful to show you exactly where the issue is.

comment:29 Changed 7 months ago by kencu (Ken)

soprano has a +debug variant, but it doesn't work sufficiently to debug anything.

If you add this to the soprano Portfile, you can install it with all the needed optimization disabled:

configure.optflags-replace -Os -O0

once soprano is also installed properly

sudo port -f uninstall soprano
sudo port -v -s -k install soprano +debug

then you can scroll through all the soprano source as well when debugging.

comment:30 Changed 6 months ago by RJVB (René Bertin)

Some thoughts:

  • if raptor2 is a potential culprit, does downgrading that port to the version available when KDE4 was last known to build help? I'll try to remember to run some of the commands mentioned above with my old install (that hasn't been changed for years).
  • what about building soprano with -DSOPRANO_DISABLE_RAPTOR_PARSER=ON -DSOPRANO_DISABLE_RAPTOR_SERIALIZER=ON to avoid using raptor alltogether? (That'll drop the Redland dep also.)
  • does it only crash when parsing the nepomuk stuff (tmo.trig) or also on other files?

IIRC nepomuk was already deprecated by the end of KDE4 and was always (?) optional so a priori a lot easier to do without than soprano .

Both are optional dependencies of kdelibs4:

macro_optional_find_package(Soprano 2.7.56 COMPONENTS PLUGIN_RAPTORPARSER PLUGIN_REDLANDBACKEND)
set_package_properties(Soprano PROPERTIES DESCRIPTION "Support for the Nepomuk semantic desktop system"
                       URL "http://soprano.sourceforge.net"
                       TYPE OPTIONAL
                      )
   
macro_optional_find_package(SharedDesktopOntologies 0.10)
set_package_properties(SharedDesktopOntologies PROPERTIES DESCRIPTION "Support for the Nepomuk semantic desktop system"
                       URL "http://oscaf.sourceforge.net"
                       TYPE OPTIONAL
                      )

Why not stick the nepomuk+soprano stuff in a kdelibs4 variant (from what I can tell it isn't exactly useful if you're not running a full KDE desktop) and maybe make it a default_variant if ever this problem gets sorted out?

comment:31 in reply to:  30 Changed 6 months ago by barracuda156

Replying to RJVB:

Some thoughts:

  • if raptor2 is a potential culprit, does downgrading that port to the version available when KDE4 was last known to build help? I'll try to remember to run some of the commands mentioned above with my old install (that hasn't been changed for years).
  • what about building soprano with -DSOPRANO_DISABLE_RAPTOR_PARSER=ON -DSOPRANO_DISABLE_RAPTOR_SERIALIZER=ON to avoid using raptor alltogether? (That'll drop the Redland dep also.)
  • does it only crash when parsing the nepomuk stuff (tmo.trig) or also on other files?

IIRC nepomuk was already deprecated by the end of KDE4 and was always (?) optional so a priori a lot easier to do without than soprano .

Both are optional dependencies of kdelibs4:

macro_optional_find_package(Soprano 2.7.56 COMPONENTS PLUGIN_RAPTORPARSER PLUGIN_REDLANDBACKEND)
set_package_properties(Soprano PROPERTIES DESCRIPTION "Support for the Nepomuk semantic desktop system"
                       URL "http://soprano.sourceforge.net"
                       TYPE OPTIONAL
                      )
   
macro_optional_find_package(SharedDesktopOntologies 0.10)
set_package_properties(SharedDesktopOntologies PROPERTIES DESCRIPTION "Support for the Nepomuk semantic desktop system"
                       URL "http://oscaf.sourceforge.net"
                       TYPE OPTIONAL
                      )

Why not stick the nepomuk+soprano stuff in a kdelibs4 variant (from what I can tell it isn't exactly useful if you're not running a full KDE desktop) and maybe make it a default_variant if ever this problem gets sorted out?

Kdelibs4 builds without soprano, but pretty much everything further needs akonadi and nepomuk. (Well, maybe those are in reality also optional, just forced by Macports for no good reason; I did not check sources of every dependent.)

Version 0, edited 6 months ago by barracuda156 (next)

comment:32 Changed 6 months ago by kencu (Ken)

I remember looking into this idea in the past, and coming to the conclusion that the port was not going to be useful without soprano enabled at that time.

comment:33 Changed 6 months ago by RJVB (René Bertin)

https://www.reddit.com/r/kde/comments/pa80p/nepomuk_does_anyone_actually_use_it/ suggests KDEPIM uses it (vaguely rings a bell) but I can only find a reference to a share/akonadi/agents/akonadinepomukfeederagent.desktop file that references an Akonadi agent that is no longer installed neither by MacPorts nor by my old Kubuntu 14.04 Plasma4 desktop. The KDEPIM sources do NOT depend on anything installed by Nepomuk, and Akonadi itself is built WITHOUT Soprano support by default.

Starting with KDELibs 4.13, Baloo replaced the desktop search function provided by Nepomuk in earlier releases: https://userbase.kde.org/Nepomuk . That's what I referred to earlier (but couldn't remember the details of).

I've looked into the Raptor2 problem. I still had 2.0.8 installed, and onto2vocabularyclass --name TMO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/pimo/tmo.trig ran just fine with it. After upgrading to Raptor 2.0.16 from the current(?) tree, I got the same crash. I downgraded to 2.0.15 from an older ports tree, and the crash went away again. On pmo.trig; I haven't tried all those .trig files.

So we have here either a regression in Raptor, or else an API change that needs to be patched into Soprano. In that case there has to be documentation, and upstream will probably point you to it in response to the bug report that was made.

Raptor is neither big nor particularly expensive to build, so the easy way out is to do a static Raptor build in the Soprano pre-build.

But I'd really try to build port:kdelibs4 without nepomuk, e.g. by installing soprano without the Raptor and Redland plugins.

I have a hunch that the widespread dependencies on Soprano are because it's a dependency for /opt/local/lib/libnepomuk.4.dylib (part of KDElibs) and on other Unices one needs to link such indirect dependencies explicitly. I'd do this myself but I have a rather large selection of KDE ports installed which evidently all link to that nepomuk lib even if it's not used for anything; just deactivating port:soprano breaks 24 of those KDE4 ports. OTOH, deactivating the 2 nepomuk ports (core & widgets) only breaks port:kactivities. That's one of those Plasma4-desktop centric components of which I'm not certain it has any use in other contexts (but it looks like it supports building without nepomuk).

comment:34 Changed 6 months ago by kencu (Ken)

There is no functional upstream soprano.

Upstream raptor says it’s not his problem if soprano double-frees and crashes. Which is true.

I fixed the double free quite easily in soprano, but then just ran into other errors.

Kde4 is ancient… you can have stste of the art kde native on arm in 10 Minutes with UTM and a debian VM…. So that is what I recommend for people.

comment:35 in reply to:  33 Changed 6 months ago by barracuda156

Replying to RJVB:

https://www.reddit.com/r/kde/comments/pa80p/nepomuk_does_anyone_actually_use_it/ suggests KDEPIM uses it (vaguely rings a bell) but I can only find a reference to a share/akonadi/agents/akonadinepomukfeederagent.desktop file that references an Akonadi agent that is no longer installed neither by MacPorts nor by my old Kubuntu 14.04 Plasma4 desktop. The KDEPIM sources do NOT depend on anything installed by Nepomuk, and Akonadi itself is built WITHOUT Soprano support by default.

Starting with KDELibs 4.13, Baloo replaced the desktop search function provided by Nepomuk in earlier releases: https://userbase.kde.org/Nepomuk . That's what I referred to earlier (but couldn't remember the details of).

Maybe you could help with updating KDE4 in MacPorts? I would happily use it on PowerPC, and there is a KDE4 GUI for R, which is of interest for me (but due to dependencies cannot be built now).

I've looked into the Raptor2 problem. I still had 2.0.8 installed, and onto2vocabularyclass --name TMO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /opt/local/share/ontology/pimo/tmo.trig ran just fine with it. After upgrading to Raptor 2.0.16 from the current(?) tree, I got the same crash. I downgraded to 2.0.15 from an older ports tree, and the crash went away again. On pmo.trig; I haven't tried all those .trig files.

It looks like I tried an earlier version of Raptor2 with no change to the segfault. Did you build 2.0.15 or just activated an old pre-built earlier lib? It may be that not Raptor2 itself is broken, but someone else in MacPorts breaks it now.

comment:36 Changed 6 months ago by kencu (Ken)

comment:37 Changed 6 months ago by RJVB (René Bertin)

Cc: RJVB added

comment:38 Changed 6 months ago by RJVB (René Bertin)

They asked for a reproduction with rapper; I gave it to them.

As I said there, Soprano does NOT do anything obviously wrong with its memory (aka parser ptr) management. The regression has to be in raptor itself.

comment:39 in reply to:  37 Changed 6 months ago by barracuda156

Replying to RJVB:

By the way, why is the port at 4.14.3, while apparently upstream has 4.14.38? https://github.com/KDE/kdelibs/tags That's 3 years of development.

comment:40 Changed 5 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: Lev-GitHub added

Has duplicate #70164.

comment:41 Changed 5 months ago by kencu (Ken)

it has been concluded the double-free error originates in raptor2 code, and this has been fixed upstream.

unfortunately, after fixing that, raptor still errors out when parsing the needed file, and that hasn’t been fixed yet…

comment:42 in reply to:  41 Changed 5 months ago by barracuda156

Replying to kencu:

it has been concluded the double-free error originates in raptor2 code, and this has been fixed upstream.

unfortunately, after fixing that, raptor still errors out when parsing the needed file, and that hasn’t been fixed yet…

Maybe just revert the update until it is fixed? What is the benefit of having raptor with a known bug?

comment:43 Changed 5 months ago by RJVB (René Bertin)

Second that. Alternatively, use git bisect to find the commit in raptor that introduced this regression (I suppose we're talking about the reported syntax error false alarm?) and revert just that change in a patchfile until upstream fix it? If possible of course, but that way introducing an epoch would be avoided.

comment:44 Changed 5 months ago by kencu (Ken)

go for it.

which is the last version of raptor2 you can verify to work properly?

If you want to do the work to identify the exact commits that caused the issue(s), that would be great, otherwise bump the epoch, and revert to that. disable livecheck so nobody helpfully updates it, and then come back later when it is fixed.

Last edited 5 months ago by kencu (Ken) (previous) (diff)

comment:45 Changed 4 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: TheLastLovemark added

Has duplicate #70430.

comment:46 Changed 2 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: t0mbertin added

Has duplicate #70692.

comment:48 Changed 2 months ago by t0mbertin

Cc: t0mbertin removed

comment:49 Changed 2 months ago by t0mbertin

Cc: t0mbertin added
Note: See TracTickets for help on using tickets.