Segmentation fault bug, added the GDB backtrace below, thanks for the help.
10436 segmentation fault (core dumped)
Running with GDB ->>
Starting program: /usr/bin/grive
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff0d9a700 (LWP 16495)]
[Thread 0x7ffff0d9a700 (LWP 16495) exited]
Reading local directories
Reading remote server file list
[New Thread 0x7ffff0d9a700 (LWP 16532)]
[Thread 0x7ffff0d9a700 (LWP 16532) exited]
Thread 1 "grive" received signal SIGSEGV, Segmentation fault.
0x00000000004ab65b in gr::Resource::MD5[abi:cxx11]() const ()
Thanks again!
Search Criteria
Package Details: grive 0.5.3-3
Package Actions
| Git Clone URL: | https://aur.archlinux.org/grive.git (read-only, click to copy) |
|---|---|
| Package Base: | grive |
| Description: | An open source Linux client for Google Drive with support for the new Drive REST API and partial sync |
| Upstream URL: | https://github.com/vitalif/grive2 |
| Keywords: | drive Google grive2 sync vitalif |
| Licenses: | GPL2 |
| Submitter: | mrbit |
| Maintainer: | edh |
| Last Packager: | edh |
| Votes: | 282 |
| Popularity: | 0.123006 |
| First Submitted: | 2012-04-29 22:26 (UTC) |
| Last Updated: | 2024-09-14 09:14 (UTC) |
Dependencies (12)
- boost-libs
- curl (curl-quiche-gitAUR, curl-http3-ngtcp2AUR, curl-gitAUR, curl-c-aresAUR)
- expat (expat-gitAUR)
- gcc-libs (gcc-libs-gitAUR, gccrs-libs-gitAUR, gcc11-libsAUR, gcc-libs-snapshotAUR)
- json-c (json-c-gitAUR)
- libgcrypt
- yajl (yajl-gitAUR)
- boost (boost-gitAUR) (make)
- cmake (cmake-gitAUR) (make)
- binutils (optional) – backtrace and libiberty
- cppunit (optional) – unit tests
- inotify-tools (inotify-tools-gitAUR) (optional) – scheduled syncs and syncs on file change events
Required by (0)
Sources (4)
iamroot commented on 2016-09-12 16:45 (UTC)
3539037O3Ul2kNk1 commented on 2016-09-12 03:08 (UTC)
Okay, thanks. Yeah, reinstalling the package fixed it. Many thanks.
edh commented on 2016-09-11 22:32 (UTC)
@s1lentechoes
This isn't really grive's fault but probably due to the boost-lib update. Either way I increased the pkgrel to force a rebuild.
3539037O3Ul2kNk1 commented on 2016-09-11 11:38 (UTC)
Broke after an update yesterday. Error -
grive: error while loading shared libraries: libboost_program_options.so.1.60.0: cannot open shared object file: No such file or directory
edh commented on 2016-05-15 00:09 (UTC) (edited on 2016-05-15 00:11 (UTC) by edh)
@BrianAllred
Thanks for reporting the bug. Though it was neither the fault of the PKGBUILD nor grive it was still plausible to assume it is.
Apparently GCC screwed up [1] a couple of abi tags [1].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1331983#c10
[2] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/boost&id=9dbe4b8fa53e4d488f0d16309b5b1cf8b6c2c8ee
BrianAllred commented on 2016-05-14 19:11 (UTC)
@edh
Looks like it was a problem with the boost packages. They updated to 1.60.0-5 today and I was able to build and install just fine. Thanks for being patient with me!
BrianAllred commented on 2016-05-14 14:10 (UTC)
Filed an issue here:
https://github.com/vitalif/grive2/issues/75
Hopefully the dev can shed some light on this, because I agree, it's very strange.
edh commented on 2016-05-14 11:33 (UTC)
@BrianAllred
In this case be sure to file a bug report at the github repo of grive2. The building is done in compliance with the documentation and if it does not even build when followed by hand then there is a bug in the project itself.
This is getting quite strange...
BrianAllred commented on 2016-05-14 01:45 (UTC)
Interesting, I still get the same error when building manually.
edh commented on 2016-05-13 23:24 (UTC)
@BrianAllred
In case gcc fails, I would have expected that one would be unable to build it manually as well. Since it is building just fine if the PKGBUILD is sourced and executed, my first assumption was that a makepkg/pacman update broke it. Therefore I reverted the changed C*FLAGS and tried again but with no success so far.
Please be sure to let me know of any other correlations you might have thought of.
Pinned Comments
edh commented on 2023-10-11 23:00 (UTC)
If you encounter errors similar to
error [...] loading shared libraries, you most likely need to rebuilt the grive package. Usually no further action is needed except for forcing a rebuilt.The error is due to grive having been built against an older version of the library mentioned in the error message. The library has likely since been updated by
pacmanand grive need to be made aware of this by rebuilding it.