Nixpkgs: nextcloud-client 3.0.3 crashes

[turion]

Describe the bug

Since I last updated, the Nextcloud client consistently crashes. I've installed it via home-manager.

To Reproduce
Steps to reproduce the behavior:

$ systemctl --user restart nextcloud-client.service 

$ systemctl --user status nextcloud-client.service 
● nextcloud-client.service - Nextcloud Client
     Loaded: loaded (/nix/store/pnlqj1ax06nqj62pw6awjq3kf58r205b-home-manager-files/.config/systemd/user/nextcloud-client.service; enabled; vendor preset: enabled)
     Active: failed (Result: signal) since Fri 2020-11-13 11:20:26 CET; 1s ago
    Process: 5329 ExecStart=/nix/store/4zp0f109q5z515nfah3nskkfk901i8rn-nextcloud-client-3.0.3/bin/nextcloud (code=killed, signal=SEGV)
   Main PID: 5329 (code=killed, signal=SEGV)

Nov 13 11:20:24 nixos systemd[2107]: Started Nextcloud Client.
Nov 13 11:20:26 nixos systemd[2107]: nextcloud-client.service: Main process exited, code=killed, status=11/SEGV
Nov 13 11:20:26 nixos systemd[2107]: nextcloud-client.service: Failed with result 'signal'.
Nov 13 11:20:26 nixos systemd-coredump[5342]: Process 5329 (.nextcloud-wrap) of user 1000 dumped core.

Notify maintainers

@caugner

Metadata

• system: "x86_64-linux"
• host os: Linux 5.4.70, NixOS, 21.03pre246543.24c9b05ac53 (Okapi)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.3.7
• channels(root): "musnix, nixos-21.03pre251123.b839d4a8557, nixos-hardware"
• channels(turion): "home-manager, nixpkgs-21.03pre251123.b839d4a8557, nixos-19.03-19.03.173691.34c7eb7545d"
• nixpkgs: /home/turion/.nix-defexpr/channels/nixpkgs

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
nextcloud-client

[caugner]

@turion Unfortunately I'm not familiar with home-manager, but let's try and figure this out.

• Can you find out the exact channel version of the last configuration before the crash?
• Is it normal that you have nixpkgs-21.03pre and nixos-19.03 channels enabled at the same time?

[bachp]

This also happens for me when using nextcloud-client on nixos without home-manager.

[caugner]

@bachp Do you have any interesting error messages apart from the segfault when running the client with debug enabled:

nextcloud --logdebug --logfile nextcloud-debug.log

[bachp]

No but I made an odd observation.

I wanted to check if 3.0.2 also crashes so I reverted https://github.com/NixOS/nixpkgs/commit/ea161a63070ee425a1937a2d49d2557ca0f88d4f in my nixpkgs. As I expected version 3.0.2 did not crash.

So "un-reverted" the above commita and went back to 3.0.3. And to my suprise it is working now too.

What I don't know know is if the problem was that I went from an older version (3.0.0 or 3.0.1, unfortunatly I ran garbage collect so I don't know) directly to 3.0.3 and there was some incompatiblity in the config that was fixed by having 3.0.2 in between?

[caugner]

I was able to reproduce the issue locally after switching temporarily from 3.0.2 @ nixos-20.10 to 3.0.3 @ nixos-unstable.

```console
$ nextcloud --logdebug --logfile nextcloud-debug.log
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
[1] 11972 segmentation fault (core dumped) nextcloud --logdebug --logfile nextcloud-debug.log

$ tail nextcloud-debug.log
2020-11-13 18:10:24:498 [ debug nextcloud.sync.database ] [ OCC::SyncJournalDb::commitInternal ]: Transaction commit "update database structure: add e2eMangledName index" and starting new transaction
2020-11-13 18:10:24:498 [ debug nextcloud.sync.database.sql ] [ OCC::SqlQuery::exec ]: SQL exec "PRAGMA table_info('blacklist');"
2020-11-13 18:10:24:498 [ debug nextcloud.sync.database ] [ OCC::SyncJournalDb::tableColumns ]: Columns in the current journal: QVector("path", "lastTryEtag", "lastTryModtime", "retrycount", "errorstring", "lastTryTime", "ignoreDuration", "renameTarget", "errorCategory")
2020-11-13 18:10:24:498 [ debug nextcloud.sync.database.sql ] [ OCC::SqlQuery::exec ]: SQL exec "CREATE INDEX IF NOT EXISTS blacklist_index ON blacklist(path collate nocase);"
2020-11-13 18:10:24:498 [ debug nextcloud.sync.database.sql ] [ OCC::SqlQuery::exec ]: Last exec affected 0 rows.
2020-11-13 18:10:24:498 [ debug nextcloud.sync.database ] [ OCC::SyncJournalDb::commitInternal ]: Transaction commit "checkConnect End"
2020-11-13 18:10:24:498 [ debug nextcloud.sync.database.sql ] [ OCC::SqlQuery::exec ]: SQL exec "SELECT COUNT(*) FROM metadata"
2020-11-13 18:10:24:498 [ debug nextcloud.sync.database.sql ] [ OCC::SqlQuery::bindValue ]: SQL bind 1 QVariant(int, 3)
2020-11-13 18:10:24:498 [ debug nextcloud.sync.database.sql ] [ OCC::SqlQuery::exec ]: SQL exec "SELECT path FROM selectivesync WHERE type=?1"
2020-11-13 18:10:24:499 [ info nextcloud.sync.clientproxy ]: Set proxy configuration to use the preferred system proxy for http tcp connections
```

I would guess it's an upstream bug.

[caugner]

@bachp Would you be able to checkout nixpkgs at 57883eea4a4d8fad22261c11820df6b8abc53f16 and cherry-pick ea161a63070ee425a1937a2d49d2557ca0f88d4f? If it also crashes, we know it's an upstream bug.

[caugner]

Would you be able to checkout nixpkgs at 57883ee and cherry-pick ea161a6? If it also crashes, we know it's an upstream bug.

Just did this myself (after figuring out how that works, hadn't done it in a while) and indeed nextcloud still crashes after cherry-picking ea161a63070ee425a1937a2d49d2557ca0f88d4f onto 57883eea4a4d8fad22261c11820df6b8abc53f16, so it's almost certainly an upstream bug.

[caugner]

Note to myself: https://github.com/nextcloud/desktop/commit/3427dadaeb3527e6fe395b5aa5a0e6b299afc98b breaks the Nix build for 3.1.0-rc1:

[ 26%] Building CXX object src/libsync/CMakeFiles/nextcloudsync.dir/creds/abstractcredentials.cpp.o
[ 27%] Building CXX object src/libsync/CMakeFiles/nextcloudsync.dir/creds/credentialscommon.cpp.o
[ 27%] Building CXX object src/libsync/CMakeFiles/nextcloudsync.dir/creds/keychainchunk.cpp.o
[ 29%] Building CXX object src/libsync/CMakeFiles/nextcloudsync.dir/creds/httpcredentials.cpp.o
[ 29%] Building CXX object src/libsync/CMakeFiles/nextcloudsync.dir/creds/dummycredentials.cpp.o
[ 30%] Building CXX object src/libsync/CMakeFiles/nextcloudsync.dir/syncfilestatustracker.cpp.o
[ 30%] Linking CXX shared library libnextcloudsync.so
/nix/store/1ar9gcmvikdk1wij0cw4fnwvl5i07ag1-binutils-2.31.1/bin/ld: cannot find -lsecret-1
collect2: error: ld returned 1 exit status
make[2]: *** [src/libsync/CMakeFiles/nextcloudsync.dir/build.make:732: src/libsync/libnextcloudsync.so.3.0.81] Error 1
make[1]: *** [CMakeFiles/Makefile2:418: src/libsync/CMakeFiles/nextcloudsync.dir/all] Error 2
make: *** [Makefile:171: all] Error 2
builder for '/nix/store/y22zm5yjc2m6dh3p34sfl8ajhisba6ss-nextcloud-client-3.1.0-rc1.drv' failed with exit code 2
error: build of '/nix/store/y22zm5yjc2m6dh3p34sfl8ajhisba6ss-nextcloud-client-3.1.0-rc1.drv' failed

[caugner]

Now I arrived at the same point as @bachp in https://github.com/NixOS/nixpkgs/issues/103680#issuecomment-726875811 where the crash is suddenly no longer reproducible.

[caugner]

It would probably help to gdb the nextcloud-client, but I have no clue how this works in Nix.

(nix-build -E 'with import <nixpkgs> {}; enableDebugging nextcloud-client', as suggested in the Forum, doesn't work.)

[caugner]

If anybody finds out how the package can be built with enableDebugging (or keepDebugInfos), it would be possible to have a look at the coredump (identified via coredumpctl and displayed via coredumpctl gdb <PID>), which hopefully has a stacktrace to narrow down the culprit.

PS: Other things I tried that didn't work:

• Adding "-DCMAKE_BUILD_TYPE=Debug" to the cmakeFlags.
• Running nix-build -I nixpkgs=. -E 'import <nixpkgs> {overlays = [(self: super: { stdenv = super.keepDebugInfo super.stdenv; } )];}' -A nextcloud-client (caused everything to be built with keepDebugInfo, not just our nextcloud-client).

[hoppla20]

If anybody just wants a quickfix (using 3.0.2 instead of 3.0.3) you can use this overlay

self: super:
{
  nextcloud-client = super.nextcloud-client.overrideAttrs (old: {
    version = "3.0.2";

    src = super.fetchFromGitHub {
      owner = "nextcloud";
      repo = "desktop";
      rev = "v3.0.2";
      sha256 = "0qzriiaj6sjdkgh61iihvpsvhi0kvfwjz1vvjnwdlfdx2s4xmv24";
    };
  });
}

[caugner]

@turion @bachp @hoppla20 Would any of you be able to provide a backtrace?

[bachp]

@caugner Unfortunalty I'm not able to reproduce the issue anymore.

[oxapentane]

Same here. Just rebuild my system with nextcloud from the channel, seems to work perfectly...

[turion]

Same :/ very strange. Close? Or write a nixos test and bisect?

[cptMikky]

In my case the segfault yields:

$ nextcloud
2020-11-20 13:53:58:001 [ debug default ]   [ unknown ]:    static bool LibSecretKeyring::findPassword(const QString&, const QString&, QKeychain::JobPrivate*)
[1]    3985 segmentation fault (core dumped)  nextcloud

So apparenty, at least for me, the segfault is related to keychain.

Guys, what's your working 3.0.3 package hash?
I've got a chance to test these two and both segfault in the same way:

/nix/store/4zp0f109q5z515nfah3nskkfk901i8rn-nextcloud-client-3.0.3
/nix/store/cgbzjarf3z4b8yq35mv25qbcki51kfdl-nextcloud-client-3.0.3

[caugner]

@cptMikky Thanks! I have forwarded to the nextcloud/desktop repository.

Out of interest, how did you manage to retrieve that backtrace ?

Update: Oh, I'm getting the same debug line now. Afaik it's not a proper backtrace though.

[cptMikky]

It's just what it spews to the stdout :) I was kind of surprised I didn't see that information anywhere above, that's why I posted it. I can try to do the actual backtrace if it may be beneficial.

[turion]

I have:

$ ls /nix/store/*nextcloud-client-3.0.3/bin/nextcloud
/nix/store/4zp0f109q5z515nfah3nskkfk901i8rn-nextcloud-client-3.0.3/bin/nextcloud  /nix/store/cgbzjarf3z4b8yq35mv25qbcki51kfdl-nextcloud-client-3.0.3/bin/nextcloud

So probably exactly the same executables. But I didn't observe any segfaults since a few days. Weird.

[turion]

If you want, we can check whether the build was reproducible:

$ md5sum /nix/store/4zp0f109q5z515nfah3nskkfk901i8rn-nextcloud-client-3.0.3/bin/nextcloud
f0691038eae95fc27d9290449bf7b17e  /nix/store/4zp0f109q5z515nfah3nskkfk901i8rn-nextcloud-client-3.0.3/bin/nextcloud

$ md5sum /nix/store/cgbzjarf3z4b8yq35mv25qbcki51kfdl-nextcloud-client-3.0.3/bin/nextcloud
570c7425d0ae9d4264375991b6062769  /nix/store/cgbzjarf3z4b8yq35mv25qbcki51kfdl-nextcloud-client-3.0.3/bin/nextcloud

[cptMikky]

My binaries have the same checksum so I guess the problem may not be in the nextcloud client itself.