Opened 13 years ago

Closed 12 years ago

#2301 closed Bug (invalid)

Valgrind complains about tr_bencToStr

Reported by: jch Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.73
Severity: Minor Keywords:
Cc:

Description

Charles, is that worrying?

==13917== Syscall param write(buf) points to uninitialised byte(s)
==13917==    at 0x8A37F1B: (within /lib/libc-2.9.so)
==13917==    by 0x89E4069: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1275)
==13917==    by 0x89E3CC9: new_do_write (fileops.c:529)
==13917==    by 0x89E3FAD: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1369)
==13917==    by 0x89D9EB7: fwrite (iofwrite.c:45)
==13917==    by 0x440D8D: tr_bencToFile (bencode.c:1550)
==13917==    by 0x478982: tr_torrentSaveResume (resume.c:515)
==13917==    by 0x45605C: tr_torrentStop (torrent.c:1369)
==13917==    by 0x42B2A0: stopTorrentForeach (main.c:1197)
==13917==    by 0x503ABB7: gtk_tree_selection_selected_foreach (in /usr/lib/libtk-x11-2.0.so.0.1600.1)
==13917==    by 0x42B82C: doAction (main.c:1358)
==13917==    by 0x41D8F0: action_cb (actions.c:36)
==13917==  Address 0x12187b1a is 242 bytes inside a block of size 6,197 alloc'd
==13917==    at 0x4C2391E: malloc (vg_replace_malloc.c:207)
==13917==    by 0x45E5B9: tr_malloc (utils.h:286)
==13917==    by 0x45E60E: tr_strndup (utils.c:714)
==13917==    by 0x440C9A: tr_bencToStr (bencode.c:1526)
==13917==    by 0x440D71: tr_bencToFile (bencode.c:1548)
==13917==    by 0x478982: tr_torrentSaveResume (resume.c:515)
==13917==    by 0x45605C: tr_torrentStop (torrent.c:1369)
==13917==    by 0x42B2A0: stopTorrentForeach (main.c:1197)
==13917==    by 0x503ABB7: gtk_tree_selection_selected_foreach (in /usr/lib/libtk-x11-2.0.so.0.1600.1)
==13917==    by 0x42B82C: doAction (main.c:1358)
==13917==    by 0x41D8F0: action_cb (actions.c:36)
==13917==    by 0x6D4B11C: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.200.1)
==13917== 

Change History (21)

comment:1 Changed 13 years ago by charles

  • Summary changed from Valgrind complains about tr_torrentStop to Valgrind complains about tr_bencToStr

I've seen that warning before, but was never able to track it down...

comment:2 Changed 12 years ago by charles

jch: would you be able to isolate which torrent is generating this message, and mail me its corresponding .resume file from ~/.config/transmission*/resume/ ?

comment:3 Changed 12 years ago by charles

jch: more specifically, I'm looking for a valgrind message like "Address 0xblabla is $NUMBER bytes inside a block of..." and wondering what begins at character # $NUMBER in the corresponding .resume file. So $NUMBER might not be 242 each time.

comment:4 Changed 12 years ago by jch

Sent by private mail. The .resume file has changed since then, but at the time, 242 would bring us somewhere in the middle of the peers array in the resume file, which contains a suspiciously large number of binary zeroes. Looks like corruption to me.

--Juliusz

comment:5 Changed 12 years ago by charles

I've committed a possible fix for this in r8877. If you have a few minutes, could you re-run your valgrind test to see if the problem persists?

comment:6 Changed 12 years ago by jch

Sorry, I'm still getting the same warning.

--Juliusz

comment:7 Changed 12 years ago by charles

julius, I'm not able to reproduce this anymore. could you please doublecheck that the warning is coming from a fresh build; and if so, is it still 242 bytes into the file?

comment:8 follow-up: Changed 12 years ago by charles

s/julius/Juliusz/, excuse me...

comment:9 in reply to: ↑ 8 Changed 12 years ago by jch

Replying to charles:

s/julius/Juliusz/, excuse me...

You're welcome to use the proper Latin version of my name. It's only us, barbarians from beyond the Eastern marches of the Empire, who feel the need to change the spelling of everything...

Julius scripsit

comment:10 Changed 12 years ago by jch

On a different torrent:

==27167== 
==27167== Syscall param write(buf) points to uninitialised byte(s)
==27167==    at 0x8A3641B: (within /lib/libc-2.9.so)
==27167==    by 0x89E36C2: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1275)
==27167==    by 0x89E3329: new_do_write (fileops.c:529)
==27167==    by 0x89E360D: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1369)
==27167==    by 0x89D9607: fwrite (iofwrite.c:45)
==27167==    by 0x4411AF: tr_bencToFile (bencode.c:1550)
==27167==    by 0x4792D0: tr_torrentSaveResume (resume.c:516)
==27167==    by 0x4564C2: stopTorrent (torrent.c:1369)
==27167==    by 0x45D0E6: readFromPipe (trevent.c:189)
==27167==    by 0x490987: event_base_loop (event.c:392)
==27167==    by 0x45D284: libeventThreadFunc (trevent.c:239)
==27167==    by 0x44712E: ThreadFunc (platform.c:108)
==27167==  Address 0x10b1c7d3 is 3,547 bytes inside a block of size 16,738 alloc
'd
==27167==    at 0x4C2391E: malloc (vg_replace_malloc.c:207)
==27167==    by 0x45EEE5: tr_malloc (utils.h:286)
==27167==    by 0x45EF3A: tr_strndup (utils.c:714)
==27167==    by 0x4410BC: tr_bencToStr (bencode.c:1526)
==27167==    by 0x441193: tr_bencToFile (bencode.c:1548)
==27167==    by 0x4792D0: tr_torrentSaveResume (resume.c:516)
==27167==    by 0x4564C2: stopTorrent (torrent.c:1369)
==27167==    by 0x45D0E6: readFromPipe (trevent.c:189)
==27167==    by 0x490987: event_base_loop (event.c:392)
==27167==    by 0x45D284: libeventThreadFunc (trevent.c:239)
==27167==    by 0x44712E: ThreadFunc (platform.c:108)
==27167==    by 0x8761F99: start_thread (pthread_create.c:300)

This time, offset 3547 is in the middle of the bitfield field of the resume file. Which is correct (I'm a seed).

--Julius

comment:11 Changed 12 years ago by charles

Well, that's progress; we've moved past byte 242 at least. So possibly there are two separate causes for this valgrind warning...

comment:12 Changed 12 years ago by charles

I can't figure out the new warning. bitfields appear to be correctly zeroed out, and the bencode module appears to serialize it correctly, and the resume code for that is actually very simple. I'm not sure what to do about this second warning, and can't reproduce it either. :/

comment:13 Changed 12 years ago by charles

jch: ping

is this still the case in 1.74? if so, could you please attach a warning from 1.74? As I said in my comment 3 weeks ago, I can't reproduce this.

comment:14 Changed 12 years ago by charles

  • Keywords needinfo added

comment:15 Changed 12 years ago by charles

  • Resolution set to worksforme
  • Status changed from new to closed

closing from lack of information. Please feel encouraged to reopen this ticket when more information is available.

comment:16 Changed 12 years ago by jch

  • Keywords needinfo removed
  • Resolution worksforme deleted
  • Status changed from closed to reopened
==10245== Syscall param write(buf) points to uninitialised byte(s)
==10245==    at 0x8C3841B: write (in /lib/libc-2.9.so)
==10245==    by 0x8BE56C2: _IO_file_write (in /lib/libc-2.9.so)
==10245==    by 0x8BE5329: (within /lib/libc-2.9.so)
==10245==    by 0x8BE5664: _IO_do_write (in /lib/libc-2.9.so)
==10245==    by 0x8BE697F: _IO_file_close_it (in /lib/libc-2.9.so)
==10245==    by 0x8BDA1CF: fclose (in /lib/libc-2.9.so)
==10245==    by 0x4401E0: tr_bencToFile (bencode.c:1556)
==10245==    by 0x478E79: tr_torrentSaveResume (resume.c:534)
==10245==    by 0x45561F: tr_torrentSave (torrent.c:1405)
==10245==    by 0x44CD38: onSaveTimer (session.c:555)
==10245==    by 0x7447287: event_base_loop (event.c:392)
==10245==    by 0x45C5F4: libeventThreadFunc (trevent.c:239)
==10245==  Address 0x420f0d1 is not stack'd, malloc'd or (recently) free'd

comment:17 Changed 12 years ago by charles

hurm.

I'm at a loss on how to proceed with this.

Is there a way for me to reproduce this? Is this something that happens consistently for you?

If so, could you try commenting out the calls in tr_torrentSaveResume() to savePeers(), saveFilePriorities(), saveDND(), saveProgress(), saveSpeedLimits(), and saveRatioLimits() one-by-one to figure out which part of torrentSaveResume() is generating the bencoded data that's not initialized?

It's not nice to punt so much of this work to you, but unless I can find a way to trigger the behavior myself, I don't see how else to move forward on this.

comment:18 follow-up: Changed 12 years ago by charles

I'd like to figure out what's causing this bug, but I haven't heard back from you in a while. Could you please provide the requested information? Thanks!

comment:19 in reply to: ↑ 18 Changed 12 years ago by jch

Replying to charles:

I haven't heard back from you in a while.

I really cannot afford to spend time doing fun stuff right now. Sorry for that, I hope I'll be able to come back to transmission in a few weeks' time.

comment:20 Changed 12 years ago by charles

Any news on this?

comment:21 Changed 12 years ago by jch

  • Resolution set to invalid
  • Status changed from reopened to closed

I'm unable to reproduce it; it may have been specific to a single torrent, which I may not have kept around. I'm an ass.

--Juliusz

Note: See TracTickets for help on using tickets.