| Summary: | app-crypt/gnupg-2.1.{17-r1,19}: test hangs | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Harri Nieminen (Moiman) <moiman> |
| Component: | Current packages | Assignee: | Kristian Fiskerstrand (RETIRED) <k_f> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | alonbl, crypto+disabled, pr.gentoo-acct |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=595808 https://bugs.gentoo.org/show_bug.cgi?id=605260 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info gnupg
emerge.log with FEATURES="test" strace "emerge -1 gnupg" strace gpg-agent gdb gpg-agent gdb t-protect |
||
|
Description
Harri Nieminen (Moiman)
2017-01-15 19:00:38 UTC
Created attachment 460214 [details]
emerge --info gnupg
Created attachment 460216 [details]
emerge.log with FEATURES="test"
(In reply to moikkis from comment #2) > Created attachment 460216 [details] > emerge.log with FEATURES="test" This doesn't really show a failure, can you strace the process to look at what is happening? Created attachment 460254 [details]
strace "emerge -1 gnupg"
Here is strace file
(In reply to moikkis from comment #4) > Created attachment 460254 [details] > strace "emerge -1 gnupg" > > Here is strace file double gzipped... curious approach to things. But I'm more curious about the gpg-agent you say is halted than emerge.. Created attachment 460300 [details]
strace gpg-agent
Created attachment 460304 [details]
gdb gpg-agent
(In reply to moikkis from comment #7) > Created attachment 460304 [details] > gdb gpg-agent Thanks, this is useful. Will look into it when more time - no immediate thoughts, although with this info it does look to underlying cause could be related to bug 595808 after all (but in any case better to track as separate bug). Setting see also, although this bug happens with smartcard support off Upstream response: """ Err. From the log it doesn't seem like a test is run at all. Please ask the reporter to figure out what is actually happening. The log ends in make check-TESTS make[2]: Entering directory '/var/tmp/portage/app-crypt/gnupg-2.1.17-r1/work/gnupg-2.1.17/agent' however, there are no tests in agent/ that actually spawn the agent. So, what agent process are we even looking at? Further, from the stack trace I see that npth is trying to acquire the global npth lock. This suggests that more threads are running. Please ask the reporter to do 'thread apply all bt'. Justus """ (In reply to Kristian Fiskerstrand from comment #10) > Upstream response: > """ > Err. From the log it doesn't seem like a test is run at all. Please > ask the reporter to figure out what is actually happening. The log ends > in > > make check-TESTS > make[2]: Entering directory > '/var/tmp/portage/app-crypt/gnupg-2.1.17-r1/work/gnupg-2.1.17/agent' > > however, there are no tests in agent/ that actually spawn the agent. > So, what agent process are we even looking at? > > Further, from the stack trace I see that npth is trying to acquire the > global npth lock. This suggests that more threads are running. Please > ask the reporter to do 'thread apply all bt'. > > > Justus > """ Ohh, I confused two bugs. Strace and gdb output are for gpg-agent that hang after pinentry when generating new keys. Does the issue persist in 2.1.19? Created attachment 465812 [details]
gdb t-protect
Yes, issue still persist in 2.1.19 .
I attached the right gdb trace now.
Test passes if I am compiling something while tests run. But if I'm not compiling while test runs it hangs. If I start compiling something after test has hanged it doesn't help.
(In reply to moikkis from comment #13) > Test passes if I am compiling something while tests run. But if I'm not > compiling while test runs it hangs. If I start compiling something after > test has hanged it doesn't help. Okay I given enough time and compiling in background test passes. Maybe I just have some entropy problems or something. thanks, please reopen if you still experience this. (In reply to Alon Bar-Lev from comment #15) > thanks, please reopen if you still experience this. I ended up having this problem myself for the last few months. today I decided to look into it. long story short a tickless kernel will make the agent wrongly detect the speed of encryption and thus it keeps incrementing the number of iterations sent to gcrypt lib function. an upstream bug has been filed here: https://dev.gnupg.org/T3276 |
