the git branch main hash 9afced7 crash #5677
Comments
|
Which application of Transmission? |
lindianfeng
changed the title
|
OS:debain 12 Transmission Version: main-dev |
|
What caused the crash? Is it SEGV? |
|
int frame 2 |
yes,it is the SEGV |
|
What was Transmission doing when it crashed? Was it just starting up or shutting down? |
It was not starting or shutting down,it was seeding |
|
That does not make sense to me... I wonder if something else wrote to |
|
This crash only occurs in the main branch, but not in the 4.0.3 branch. I try to start it with valgrind to see if there is a memory out of bounds. I will post the results here when I make progress, thank you |
|
==15059== Warning: set address range perms: large range [0x664be028, 0x7f523858) (noaccess) |
|
==15059== Invalid write of size 8 |
|
==15059== Invalid read of size 8 |
ckerr
changed the title
|
hash: ce66e5c ==45972== Process terminating with default action of signal 11 (SIGSEGV) |
|
==45972== Invalid write of size 8 |
|
==45972== Invalid read of size 8 |
|
all the valgrind check log hash:ce66e |
|
I think it has something to do with changing the small library in the code, it didn’t crash before |
|
@lindianfeng the more I read this valgrind log the more confusing it is -- it seems like you're hitting some states that just shouldn't be reached. Can you confirm for me that you're using an unmodified version of |
Maybe? I don't have another theory at the moment because the valgrind log is really strange, but... if it's just |
ikr?? So it is not just me |
|
@lindianfeng Did you run valgrind with |
|
example: I don't see any code path for |
|
Just brainstorming, maybe asan would be useful as a second reference point. Something like
And if it gives the same output as Valgrind then that will at least prove that Valgrind's not hiccuping here |
|
I compiled it with gcc，and run cmd is： |
|
cmake .. -DENABLE_DAEMON=ON -DENABLE_GTK=OFF -DENABLE_QT=OFF -DENABLE_MAC=OFF -DINSTALL_WEB=OFF -DINSTALL_DOC=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=/usr && make -j6 |
commit 8183d7f (HEAD -> main, origin/main, origin/HEAD) |
|
Linux version 6.1.0-9-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) |
|
clang: glibc: code version: build cmd: errors: 0x6140007327b0 is located 368 bytes inside of 392-byte region [0x614000732640,0x6140007327c8) previously allocated by thread T1 here: Thread T1 created by T0 here: SUMMARY: AddressSanitizer: heap-use-after-free /home/kaka/code/transmission/libtransmission/../libtransmission/handshake.h:160:16 in tr_handshake::state() const |
|
/home/kaka/code/transmission/libtransmission/handshake.cc:693:28 auto* handshake = static_cast<tr_handshake*>(vhandshake); maybe the var 'handshake' is be freed |
|
I have not changed the code, I can cooperate with the test, thank you for your contribution |
|
try agin and open the trace log [2023-07-01 02:11:17.202] trc [122.194.56.72]:58803 48 overhead bytes via utp (peer-io.cc:734) 0x6140005997b0 is located 368 bytes inside of 392-byte region [0x614000599640,0x6140005997c8) previously allocated by thread T1 here: Thread T1 created by T0 here: SUMMARY: AddressSanitizer: heap-use-after-free /home/kaka/code/transmission/libtransmission/../libtransmission/handshake.h:175:29 in tr_handshake::state_string() const |
|
Well looks like it agrees with Valgrind 🤷♂️ so even though I don't understand the crash yet, I know where to keep looking 😸 |
ckerr
added
bug:regression
and removed
needs clarification
ok！ contact me if you need my help |
|
@tearfur, just brainstorming... if there is a bug in #5651 that I can't see, that could cause the wrong handshake to be removed from @lindianfeng you could test this theory ^ from a local build by running |
|
@lindianfeng I think you are right... For example @ckerr #5651 should be reverted for now, and some new tests are needed. Perhaps this will be worth reconsidering if we ever move to C++20, where we have |
|
revert after it work fine Loaded: loaded (/lib/systemd/system/transmission-daemon.service; enabled; preset: enabled) |
|
@lindianfeng Would you please help test #5709? |
OK，I'll test it when I get home |
i am already build it and testing |
@tearfur I don't think I understand this bug yet. Even if @lindianfeng you've been super helpful with testing out ideas + valgrind + asan like this. Thank you!! I wish all bug reporters were this helpful 🙇♂️ |
|
@ckerr Me neither, but reverting the PR is the least I can do now. I agree that |
I am very glad to help you, I am doing c++ development and developing the games |
|
The good news is that after the fallback, the crash hasn't happened yet |
can chang std::map to std::unordered_map? |
|
That could help, but |
|
Oh and since it's merged I guess I should close this ticket 😸 but @lindianfeng if this issue comes back and/or if you see any others feel free to give a yell. Actually we can always use more C++ developers so feel free to check out the any of the open tickets as well 😉 |
if int64_t{ ntohl(this->addr.addr4.s_addr) } - ntohl(that.addr.addr4.s_addr) result is 0x100000000000 ,cast to int it will is the zero, return equal ，in fact they are not equal. |
What is the issue?
Which application of Transmission?
None
Which version of Transmission?
No response
The text was updated successfully, but these errors were encountered: