Crash with showing the downloading file per peer #3751

Closed
opened 2026-02-21 16:56:39 -05:00 by deekerman · 85 comments
Owner

Originally created by @hdcTenBasePid on GitHub (Jan 19, 2016).

Ver - OpenVPN 2.3.10 , Tap 9.0.21.1

I an using advanced adapter setting to select VPN adapter.
Although a crash is reported, qBit continues even now as I type this. Here is your info:

qBittorrent version: v3.3.2
Libtorrent version: 1.0.8.0
Qt version: 5.5.1
Boost version: 1.60.0

#  0 qbittorrent.exe      0x0000000001239adf straceWin::getBacktrace()
#  1 qbittorrent.exe      0x000000000123bef2 sigsegvHandler(__formal)
#  2 qbittorrent.exe      0x0000000001a09353 _seh_filter_exe(xcptnum, pxcptinfoptrs)
#  3 qbittorrent.exe      0x00000000019efd90 __scrt_common_main_seh()
#  4 qbittorrent.exe      0x00000000019f5660 _EH4_CallFilterFunc()
#  5 qbittorrent.exe      0x00000000019f4381 _except_handler4(ExceptionRecord, EstablisherFrame, ContextRecord, DispatcherContext)
#  6 ntdll.dll            0x0000000076f3b562 RtlConvertUlongToLargeInteger()
#  7 ntdll.dll            0x0000000076f3b534 RtlConvertUlongToLargeInteger()
#  8 ntdll.dll            0x0000000076f28daf KiUserExceptionDispatcher()
#  9 qbittorrent.exe      0x00000000018d8372 libtorrent::internal_file_entry::filename()
#10 qbittorrent.exe      0x00000000018d81c5 libtorrent::file_storage::file_path(index, save_path, save_path)
#11 qbittorrent.exe      0x000000000126c9b8 BitTorrent::TorrentInfo::filePath(index, index)
#12 qbittorrent.exe      0x000000000126cdfa BitTorrent::TorrentInfo::filesForPiece(pieceIndex)
#13 qbittorrent.exe      0x00000000012afb94 PeerListWidget::updatePeer(ip, torrent, peer)
#14 qbittorrent.exe      0x00000000012ae92e PeerListWidget::loadPeers(torrent, forceHostnameResolution)
#15 qbittorrent.exe      0x00000000012a9522 PropertiesWidget::loadDynamicData()
#16 qbittorrent.exe      0x0000000001313c40 PropertiesWidget::qt_static_metacall(_o, _c, _id, _a)
#17 qbittorrent.exe      0x00000000016d18db QMetaObject::activate()
#18 qbittorrent.exe      0x00000000016d147f QMetaObject::activate()
#19 qbittorrent.exe      0x0000000001742455 QTimer::timeout()
#20 qbittorrent.exe      0x00000000016f4a77 QTimer::timerEvent()
#21 qbittorrent.exe      0x00000000016cec70 QObject::event()
#22 qbittorrent.exe      0x00000000013a7b75 QApplicationPrivate::notify_helper()
#23 qbittorrent.exe      0x00000000013a769c QApplication::notify()
#24 qbittorrent.exe      0x0000000001237d71 Application::notify(receiver, event)
#25 qbittorrent.exe      0x00000000016f1ce0 QCoreApplication::notifyInternal()
#26 qbittorrent.exe      0x00000000013aa1ca QCoreApplication::sendEvent()
#27 qbittorrent.exe      0x00000000017842f9 QEventDispatcherWin32Private::sendTimerEvent()
#28 qbittorrent.exe      0x0000000001783d6a qt_internal_proc()
#29 USER32.dll           0x00000000769584f3 SetManipulationInputTarget()
#30 USER32.dll           0x0000000076936c40 CallWindowProcW()
#31 USER32.dll           0x0000000076936541 DispatchMessageW()
#32 USER32.dll           0x0000000076936300 DispatchMessageW()
#33 qbittorrent.exe      0x0000000001784899 QEventDispatcherWin32::processEvents()
#34 qbittorrent.exe      0x00000000017d31d1 QWindowsGuiEventDispatcher::processEvents()
#35 qbittorrent.exe      0x000000000175a214 QEventLoop::exec()
#36 qbittorrent.exe      0x00000000016f1fec QCoreApplication::exec()
#37 qbittorrent.exe      0x0000000001237ba2 Application::exec(params)
#38 qbittorrent.exe      0x000000000123bad8 main(argc, argv)
#39 qbittorrent.exe      0x000000000186d535 WinMain()
#40 qbittorrent.exe      0x00000000019efd49 __scrt_common_main_seh()
#41 KERNEL32.DLL         0x00000000743438f4 BaseThreadInitThunk()
#42 ntdll.dll            0x0000000076f156c3 RtlUnicodeStringToInteger()
#43 ntdll.dll            0x0000000076f1568e RtlUnicodeStringToInteger()


List of linked Modules:
qbittorrent               0x0000000001210000 Image: C:\Program Files (x86)\qBittorrent\qbittorrent.exe
                                    .\qbittorrent.pdb
ntdll                     0x0000000076eb0000 Image: C:\WINDOWS\SYSTEM32\ntdll.dll
KERNEL32                  0x0000000074330000 Image: C:\WINDOWS\SYSTEM32\KERNEL32.DLL
KERNELBASE                0x0000000074cf0000 Image: C:\WINDOWS\SYSTEM32\KERNELBASE.dll
USER32                    0x0000000076920000 Image: C:\WINDOWS\SYSTEM32\USER32.dll
GDI32                     0x0000000076390000 Image: C:\WINDOWS\SYSTEM32\GDI32.dll
POWRPROF                  0x0000000076d70000 Image: C:\WINDOWS\SYSTEM32\POWRPROF.dll
dbghelp                   0x0000000072390000 Image: C:\WINDOWS\SYSTEM32\dbghelp.dll
msvcrt                    0x0000000074560000 Image: C:\WINDOWS\SYSTEM32\msvcrt.dll
RPCRT4                    0x0000000074ba0000 Image: C:\WINDOWS\SYSTEM32\RPCRT4.dll
SspiCli                   0x0000000073be0000 Image: C:\WINDOWS\SYSTEM32\SspiCli.dll
CRYPTBASE                 0x0000000073bd0000 Image: C:\WINDOWS\SYSTEM32\CRYPTBASE.dll
bcryptPrimitives          0x0000000074c50000 Image: C:\WINDOWS\SYSTEM32\bcryptPrimitives.dll
sechost                   0x0000000073c10000 Image: C:\WINDOWS\SYSTEM32\sechost.dll
OLEAUT32                  0x0000000076a80000 Image: C:\WINDOWS\SYSTEM32\OLEAUT32.dll
combase                   0x0000000076bb0000 Image: C:\WINDOWS\SYSTEM32\combase.dll
IMM32                     0x0000000074cb0000 Image: C:\WINDOWS\SYSTEM32\IMM32.dll
CRYPT32                   0x0000000074910000 Image: C:\WINDOWS\SYSTEM32\CRYPT32.dll
MSASN1                    0x0000000076a70000 Image: C:\WINDOWS\SYSTEM32\MSASN1.dll
SHELL32                   0x0000000074e70000 Image: C:\WINDOWS\SYSTEM32\SHELL32.dll
WINMM                     0x0000000073390000 Image: C:\WINDOWS\SYSTEM32\WINMM.dll
cfgmgr32                  0x0000000074870000 Image: C:\WINDOWS\SYSTEM32\cfgmgr32.dll
windows.storage           0x0000000073c60000 Image: C:\WINDOWS\SYSTEM32\windows.storage.dll
advapi32                  0x00000000747f0000 Image: C:\WINDOWS\SYSTEM32\advapi32.dll
shlwapi                   0x00000000741e0000 Image: C:\WINDOWS\SYSTEM32\shlwapi.dll
kernel.appcore            0x0000000074b90000 Image: C:\WINDOWS\SYSTEM32\kernel.appcore.dll
WINMMBASE                 0x0000000000d20000 Image: C:\WINDOWS\SYSTEM32\WINMMBASE.dll
shcore                    0x0000000076e20000 Image: C:\WINDOWS\SYSTEM32\shcore.dll
profapi                   0x0000000074ce0000 Image: C:\WINDOWS\SYSTEM32\profapi.dll
ole32                     0x0000000074aa0000 Image: C:\WINDOWS\SYSTEM32\ole32.dll
WS2_32                    0x00000000748b0000 Image: C:\WINDOWS\SYSTEM32\WS2_32.dll
MSWSOCK                   0x0000000073620000 Image: C:\WINDOWS\SYSTEM32\MSWSOCK.dll
version                   0x0000000073a30000 Image: C:\WINDOWS\system32\version.dll
uxtheme                   0x0000000072550000 Image: C:\WINDOWS\system32\uxtheme.dll
tiptsf                    0x000000006bd50000 Image: C:\Program Files (x86)\Common Files\Microsoft Shared\Ink\tiptsf.dll
dwmapi                    0x0000000072000000 Image: C:\WINDOWS\system32\dwmapi.dll
iphlpapi                  0x0000000073670000 Image: C:\WINDOWS\system32\iphlpapi.dll
NSI                       0x0000000073c00000 Image: C:\WINDOWS\SYSTEM32\NSI.dll
dhcpcsvc                  0x0000000072120000 Image: C:\WINDOWS\SYSTEM32\dhcpcsvc.DLL
dhcpcsvc6                 0x0000000072140000 Image: C:\WINDOWS\SYSTEM32\dhcpcsvc6.DLL
wlanapi                   0x0000000070050000 Image: C:\WINDOWS\SYSTEM32\wlanapi.dll
bcrypt                    0x00000000734c0000 Image: C:\WINDOWS\SYSTEM32\bcrypt.dll
CRYPTSP                   0x00000000720d0000 Image: C:\WINDOWS\SYSTEM32\CRYPTSP.dll
rsaenh                    0x00000000720a0000 Image: C:\WINDOWS\system32\rsaenh.dll
wshqos                    0x000000006bfa0000 Image: C:\WINDOWS\system32\wshqos.dll
wshtcpip                  0x000000006bf90000 Image: C:\WINDOWS\SYSTEM32\wshtcpip.DLL
wship6                    0x000000006bf80000 Image: C:\WINDOWS\SYSTEM32\wship6.dll
DNSAPI                    0x00000000728c0000 Image: C:\WINDOWS\SYSTEM32\DNSAPI.dll
rasadhlp                  0x0000000071260000 Image: C:\Windows\System32\rasadhlp.dll
fwpuclnt                  0x00000000736f0000 Image: C:\WINDOWS\System32\fwpuclnt.dll
MSCTF                     0x0000000076270000 Image: C:\WINDOWS\SYSTEM32\MSCTF.dll
clbcatq                   0x0000000076b20000 Image: C:\WINDOWS\SYSTEM32\clbcatq.dll
dataexchange              0x00000000614a0000 Image: C:\WINDOWS\system32\dataexchange.dll
dcomp                     0x00000000613f0000 Image: C:\WINDOWS\system32\dcomp.dll
d3d11                     0x00000000611d0000 Image: C:\WINDOWS\system32\d3d11.dll
dxgi                      0x0000000060230000 Image: C:\WINDOWS\system32\dxgi.dll
twinapi.appcore           0x0000000065330000 Image: C:\WINDOWS\system32\twinapi.appcore.dll
uiautomationcore          0x0000000060420000 Image: C:\Windows\SYSTEM32\uiautomationcore.dll
USERENV                   0x0000000073a50000 Image: C:\Windows\SYSTEM32\USERENV.dll
sxs                       0x0000000073b10000 Image: C:\WINDOWS\SYSTEM32\sxs.dll
OLEACC                    0x0000000072850000 Image: C:\Windows\SYSTEM32\OLEACC.dll
edputil                   0x0000000061100000 Image: C:\WINDOWS\SYSTEM32\edputil.dll
Originally created by @hdcTenBasePid on GitHub (Jan 19, 2016). Ver - OpenVPN 2.3.10 , Tap 9.0.21.1 I an using advanced adapter setting to select VPN adapter. Although a crash is reported, qBit continues even now as I type this. Here is your info: qBittorrent version: v3.3.2 Libtorrent version: 1.0.8.0 Qt version: 5.5.1 Boost version: 1.60.0 ``` # 0 qbittorrent.exe 0x0000000001239adf straceWin::getBacktrace() # 1 qbittorrent.exe 0x000000000123bef2 sigsegvHandler(__formal) # 2 qbittorrent.exe 0x0000000001a09353 _seh_filter_exe(xcptnum, pxcptinfoptrs) # 3 qbittorrent.exe 0x00000000019efd90 __scrt_common_main_seh() # 4 qbittorrent.exe 0x00000000019f5660 _EH4_CallFilterFunc() # 5 qbittorrent.exe 0x00000000019f4381 _except_handler4(ExceptionRecord, EstablisherFrame, ContextRecord, DispatcherContext) # 6 ntdll.dll 0x0000000076f3b562 RtlConvertUlongToLargeInteger() # 7 ntdll.dll 0x0000000076f3b534 RtlConvertUlongToLargeInteger() # 8 ntdll.dll 0x0000000076f28daf KiUserExceptionDispatcher() # 9 qbittorrent.exe 0x00000000018d8372 libtorrent::internal_file_entry::filename() #10 qbittorrent.exe 0x00000000018d81c5 libtorrent::file_storage::file_path(index, save_path, save_path) #11 qbittorrent.exe 0x000000000126c9b8 BitTorrent::TorrentInfo::filePath(index, index) #12 qbittorrent.exe 0x000000000126cdfa BitTorrent::TorrentInfo::filesForPiece(pieceIndex) #13 qbittorrent.exe 0x00000000012afb94 PeerListWidget::updatePeer(ip, torrent, peer) #14 qbittorrent.exe 0x00000000012ae92e PeerListWidget::loadPeers(torrent, forceHostnameResolution) #15 qbittorrent.exe 0x00000000012a9522 PropertiesWidget::loadDynamicData() #16 qbittorrent.exe 0x0000000001313c40 PropertiesWidget::qt_static_metacall(_o, _c, _id, _a) #17 qbittorrent.exe 0x00000000016d18db QMetaObject::activate() #18 qbittorrent.exe 0x00000000016d147f QMetaObject::activate() #19 qbittorrent.exe 0x0000000001742455 QTimer::timeout() #20 qbittorrent.exe 0x00000000016f4a77 QTimer::timerEvent() #21 qbittorrent.exe 0x00000000016cec70 QObject::event() #22 qbittorrent.exe 0x00000000013a7b75 QApplicationPrivate::notify_helper() #23 qbittorrent.exe 0x00000000013a769c QApplication::notify() #24 qbittorrent.exe 0x0000000001237d71 Application::notify(receiver, event) #25 qbittorrent.exe 0x00000000016f1ce0 QCoreApplication::notifyInternal() #26 qbittorrent.exe 0x00000000013aa1ca QCoreApplication::sendEvent() #27 qbittorrent.exe 0x00000000017842f9 QEventDispatcherWin32Private::sendTimerEvent() #28 qbittorrent.exe 0x0000000001783d6a qt_internal_proc() #29 USER32.dll 0x00000000769584f3 SetManipulationInputTarget() #30 USER32.dll 0x0000000076936c40 CallWindowProcW() #31 USER32.dll 0x0000000076936541 DispatchMessageW() #32 USER32.dll 0x0000000076936300 DispatchMessageW() #33 qbittorrent.exe 0x0000000001784899 QEventDispatcherWin32::processEvents() #34 qbittorrent.exe 0x00000000017d31d1 QWindowsGuiEventDispatcher::processEvents() #35 qbittorrent.exe 0x000000000175a214 QEventLoop::exec() #36 qbittorrent.exe 0x00000000016f1fec QCoreApplication::exec() #37 qbittorrent.exe 0x0000000001237ba2 Application::exec(params) #38 qbittorrent.exe 0x000000000123bad8 main(argc, argv) #39 qbittorrent.exe 0x000000000186d535 WinMain() #40 qbittorrent.exe 0x00000000019efd49 __scrt_common_main_seh() #41 KERNEL32.DLL 0x00000000743438f4 BaseThreadInitThunk() #42 ntdll.dll 0x0000000076f156c3 RtlUnicodeStringToInteger() #43 ntdll.dll 0x0000000076f1568e RtlUnicodeStringToInteger() List of linked Modules: qbittorrent 0x0000000001210000 Image: C:\Program Files (x86)\qBittorrent\qbittorrent.exe .\qbittorrent.pdb ntdll 0x0000000076eb0000 Image: C:\WINDOWS\SYSTEM32\ntdll.dll KERNEL32 0x0000000074330000 Image: C:\WINDOWS\SYSTEM32\KERNEL32.DLL KERNELBASE 0x0000000074cf0000 Image: C:\WINDOWS\SYSTEM32\KERNELBASE.dll USER32 0x0000000076920000 Image: C:\WINDOWS\SYSTEM32\USER32.dll GDI32 0x0000000076390000 Image: C:\WINDOWS\SYSTEM32\GDI32.dll POWRPROF 0x0000000076d70000 Image: C:\WINDOWS\SYSTEM32\POWRPROF.dll dbghelp 0x0000000072390000 Image: C:\WINDOWS\SYSTEM32\dbghelp.dll msvcrt 0x0000000074560000 Image: C:\WINDOWS\SYSTEM32\msvcrt.dll RPCRT4 0x0000000074ba0000 Image: C:\WINDOWS\SYSTEM32\RPCRT4.dll SspiCli 0x0000000073be0000 Image: C:\WINDOWS\SYSTEM32\SspiCli.dll CRYPTBASE 0x0000000073bd0000 Image: C:\WINDOWS\SYSTEM32\CRYPTBASE.dll bcryptPrimitives 0x0000000074c50000 Image: C:\WINDOWS\SYSTEM32\bcryptPrimitives.dll sechost 0x0000000073c10000 Image: C:\WINDOWS\SYSTEM32\sechost.dll OLEAUT32 0x0000000076a80000 Image: C:\WINDOWS\SYSTEM32\OLEAUT32.dll combase 0x0000000076bb0000 Image: C:\WINDOWS\SYSTEM32\combase.dll IMM32 0x0000000074cb0000 Image: C:\WINDOWS\SYSTEM32\IMM32.dll CRYPT32 0x0000000074910000 Image: C:\WINDOWS\SYSTEM32\CRYPT32.dll MSASN1 0x0000000076a70000 Image: C:\WINDOWS\SYSTEM32\MSASN1.dll SHELL32 0x0000000074e70000 Image: C:\WINDOWS\SYSTEM32\SHELL32.dll WINMM 0x0000000073390000 Image: C:\WINDOWS\SYSTEM32\WINMM.dll cfgmgr32 0x0000000074870000 Image: C:\WINDOWS\SYSTEM32\cfgmgr32.dll windows.storage 0x0000000073c60000 Image: C:\WINDOWS\SYSTEM32\windows.storage.dll advapi32 0x00000000747f0000 Image: C:\WINDOWS\SYSTEM32\advapi32.dll shlwapi 0x00000000741e0000 Image: C:\WINDOWS\SYSTEM32\shlwapi.dll kernel.appcore 0x0000000074b90000 Image: C:\WINDOWS\SYSTEM32\kernel.appcore.dll WINMMBASE 0x0000000000d20000 Image: C:\WINDOWS\SYSTEM32\WINMMBASE.dll shcore 0x0000000076e20000 Image: C:\WINDOWS\SYSTEM32\shcore.dll profapi 0x0000000074ce0000 Image: C:\WINDOWS\SYSTEM32\profapi.dll ole32 0x0000000074aa0000 Image: C:\WINDOWS\SYSTEM32\ole32.dll WS2_32 0x00000000748b0000 Image: C:\WINDOWS\SYSTEM32\WS2_32.dll MSWSOCK 0x0000000073620000 Image: C:\WINDOWS\SYSTEM32\MSWSOCK.dll version 0x0000000073a30000 Image: C:\WINDOWS\system32\version.dll uxtheme 0x0000000072550000 Image: C:\WINDOWS\system32\uxtheme.dll tiptsf 0x000000006bd50000 Image: C:\Program Files (x86)\Common Files\Microsoft Shared\Ink\tiptsf.dll dwmapi 0x0000000072000000 Image: C:\WINDOWS\system32\dwmapi.dll iphlpapi 0x0000000073670000 Image: C:\WINDOWS\system32\iphlpapi.dll NSI 0x0000000073c00000 Image: C:\WINDOWS\SYSTEM32\NSI.dll dhcpcsvc 0x0000000072120000 Image: C:\WINDOWS\SYSTEM32\dhcpcsvc.DLL dhcpcsvc6 0x0000000072140000 Image: C:\WINDOWS\SYSTEM32\dhcpcsvc6.DLL wlanapi 0x0000000070050000 Image: C:\WINDOWS\SYSTEM32\wlanapi.dll bcrypt 0x00000000734c0000 Image: C:\WINDOWS\SYSTEM32\bcrypt.dll CRYPTSP 0x00000000720d0000 Image: C:\WINDOWS\SYSTEM32\CRYPTSP.dll rsaenh 0x00000000720a0000 Image: C:\WINDOWS\system32\rsaenh.dll wshqos 0x000000006bfa0000 Image: C:\WINDOWS\system32\wshqos.dll wshtcpip 0x000000006bf90000 Image: C:\WINDOWS\SYSTEM32\wshtcpip.DLL wship6 0x000000006bf80000 Image: C:\WINDOWS\SYSTEM32\wship6.dll DNSAPI 0x00000000728c0000 Image: C:\WINDOWS\SYSTEM32\DNSAPI.dll rasadhlp 0x0000000071260000 Image: C:\Windows\System32\rasadhlp.dll fwpuclnt 0x00000000736f0000 Image: C:\WINDOWS\System32\fwpuclnt.dll MSCTF 0x0000000076270000 Image: C:\WINDOWS\SYSTEM32\MSCTF.dll clbcatq 0x0000000076b20000 Image: C:\WINDOWS\SYSTEM32\clbcatq.dll dataexchange 0x00000000614a0000 Image: C:\WINDOWS\system32\dataexchange.dll dcomp 0x00000000613f0000 Image: C:\WINDOWS\system32\dcomp.dll d3d11 0x00000000611d0000 Image: C:\WINDOWS\system32\d3d11.dll dxgi 0x0000000060230000 Image: C:\WINDOWS\system32\dxgi.dll twinapi.appcore 0x0000000065330000 Image: C:\WINDOWS\system32\twinapi.appcore.dll uiautomationcore 0x0000000060420000 Image: C:\Windows\SYSTEM32\uiautomationcore.dll USERENV 0x0000000073a50000 Image: C:\Windows\SYSTEM32\USERENV.dll sxs 0x0000000073b10000 Image: C:\WINDOWS\SYSTEM32\sxs.dll OLEACC 0x0000000072850000 Image: C:\Windows\SYSTEM32\OLEACC.dll edputil 0x0000000061100000 Image: C:\WINDOWS\SYSTEM32\edputil.dll ```
deekerman 2026-02-21 16:56:39 -05:00
  • closed this issue
  • added the
    Crash
    label
Author
Owner

@sledgehammer999 commented on GitHub (Jan 19, 2016):

Is this happening only if you use your VPN and not throught your normal connection? To be honest the above seems irrelevant to the connection method.

@sledgehammer999 commented on GitHub (Jan 19, 2016): Is this happening only if you use your VPN and not throught your normal connection? To be honest the above seems irrelevant to the connection method.
Author
Owner

@sledgehammer999 commented on GitHub (Jan 19, 2016):

There are other duplicates so it isn't a VPN related issue. It seems to occur from this implemented feature: #2885. @evsh care to take a look?
In any case, I'll try to debug this later today.

@sledgehammer999 commented on GitHub (Jan 19, 2016): There are other duplicates so it isn't a VPN related issue. It seems to occur from this implemented feature: #2885. @evsh care to take a look? In any case, I'll try to debug this later today.
Author
Owner

@hdcTenBasePid commented on GitHub (Jan 19, 2016):

Hi, It hasn't happened just thought WiFi and has only occurred once today on Vpn.
Maybe, I'm a bit premature. Will follow up if can work it out.
Regs

Sent from RB's Windows Phone


From: sledgehammer999mailto:notifications@github.com
Sent: ‎19/‎01/‎2016 8:38 PM
To: qbittorrent/qBittorrentmailto:qBittorrent@noreply.github.com
Cc: hdcTenBasePidmailto:rboras10@hotmail.com.au
Subject: Re: [qBittorrent] Crash on 10586.63 downloading through VPN (#4597)

Is this happening only if you use your VPN and not throught your normal connection? To be honest the above seems irrelevant to the connection method.


Reply to this email directly or view it on GitHub:
https://github.com/qbittorrent/qBittorrent/issues/4597#issuecomment-172792968

@hdcTenBasePid commented on GitHub (Jan 19, 2016): Hi, It hasn't happened just thought WiFi and has only occurred once today on Vpn. Maybe, I'm a bit premature. Will follow up if can work it out. Regs Sent from RB's Windows Phone --- From: sledgehammer999mailto:notifications@github.com Sent: ‎19/‎01/‎2016 8:38 PM To: qbittorrent/qBittorrentmailto:qBittorrent@noreply.github.com Cc: hdcTenBasePidmailto:rboras10@hotmail.com.au Subject: Re: [qBittorrent] Crash on 10586.63 downloading through VPN (#4597) Is this happening only if you use your VPN and not throught your normal connection? To be honest the above seems irrelevant to the connection method. --- Reply to this email directly or view it on GitHub: https://github.com/qbittorrent/qBittorrent/issues/4597#issuecomment-172792968
Author
Owner

@sledgehammer999 commented on GitHub (Jan 19, 2016):

Maybe this happens only with magnet links?

@sledgehammer999 commented on GitHub (Jan 19, 2016): Maybe this happens only with magnet links?
Author
Owner

@zeule commented on GitHub (Jan 19, 2016):

@sledgehammer999 , sure thing. @hdcTenBasePid, what is the speed of your connection and what is the piece size of the torrent which lead to this crash?

@zeule commented on GitHub (Jan 19, 2016): @sledgehammer999 , sure thing. @hdcTenBasePid, what is the speed of your connection and what is the piece size of the torrent which lead to this crash?
Author
Owner

@Nemo-qB commented on GitHub (Jan 19, 2016):

I think that I just got the same crash report, qBittorrent keeps running on the background while the crash report is showing. I had just installed it, started a new torrent and crashed within seconds. I can't seem to reproduce the crash.

@Nemo-qB commented on GitHub (Jan 19, 2016): I think that I just got the same crash report, qBittorrent keeps running on the background while the crash report is showing. I had just installed it, started a new torrent and crashed within seconds. I can't seem to reproduce the crash.
Author
Owner

@sledgehammer999 commented on GitHub (Jan 19, 2016):

This is a serious bug. I already closed another 7 duplicate reports.

@sledgehammer999 commented on GitHub (Jan 19, 2016): This is a serious bug. I already closed another 7 duplicate reports.
Author
Owner

@naikel commented on GitHub (Jan 19, 2016):

Definitely a serious bug. Looks like in this line:

res.append(filePath(s.file_index));

s.file_index can be an invalid value for filePath.

I looked examples at this kind of code in libtorrent and in all cases before accesing file_path() they validate pad_file_at like this:

if (fs.pad_file_at(s.file_index)) continue;

Because the "pad file" whatever that is doesn't have a file path or something like that.

@naikel commented on GitHub (Jan 19, 2016): Definitely a serious bug. Looks like in this line: ``` res.append(filePath(s.file_index)); ``` s.file_index can be an invalid value for filePath. I looked examples at this kind of code in libtorrent and in all cases before accesing file_path() they validate pad_file_at like this: ``` if (fs.pad_file_at(s.file_index)) continue; ``` Because the "pad file" whatever that is doesn't have a file path or something like that.
Author
Owner

@sledgehammer999 commented on GitHub (Jan 19, 2016):

@arvidn some clarification: Is the index of torrent_info::file_path() and torrent_info::files().file_path() exactly the same semantically? Or are you referring to 2 different things there?
In case you can help here is the functions' code from the backtrace:

  1. BitTorrent::TorrentInfo::filesForPiece(pieceIndex)
  2. BitTorrent::TorrentInfo::filePath(index, index)

And the index passed to BitTorrent::TorrentInfo::filesForPiece(pieceIndex) is obtained from peer_info::downloading_piece_index

@sledgehammer999 commented on GitHub (Jan 19, 2016): @arvidn some clarification: Is the index of `torrent_info::file_path()` and `torrent_info::files().file_path()` exactly the same semantically? Or are you referring to 2 different things there? In case you can help here is the functions' code from the backtrace: 1. [BitTorrent::TorrentInfo::filesForPiece(pieceIndex)](https://github.com/qbittorrent/qBittorrent/blob/master/src/base/bittorrent/torrentinfo.cpp#L214) 2. [BitTorrent::TorrentInfo::filePath(index, index)](https://github.com/qbittorrent/qBittorrent/blob/master/src/base/bittorrent/torrentinfo.cpp#L147) And the index passed to `BitTorrent::TorrentInfo::filesForPiece(pieceIndex)` is obtained from `peer_info::downloading_piece_index`
Author
Owner

@naikel commented on GitHub (Jan 19, 2016):

I'll elaborate a little more since just for the purposes of documentation. #2885 was implemented like this:

    std::vector<libtorrent::file_slice> files(
        nativeInfo()->map_block(pieceIndex, 0, nativeInfo()->piece_length()));
    QStringList res;
    for (const libtorrent::file_slice& s: files) {
        res.append(filePath(s.file_index));
    }
    return res;

And a couple of examples in libtorrent of this kind of code:

std::vector<file_slice> files = fs.map_block(
                        p.piece_index, offset, (std::min)(piece_size - offset, int(block_size())));
                int ret = 0;
                for (std::vector<file_slice>::iterator i = files.begin()
                        , end(files.end()); i != end; ++i)
                {
                        if (fs.pad_file_at(i->file_index)) continue;
                        ret += i->size;
                }
                TORRENT_ASSERT(ret <= (std::min)(piece_size - offset, int(block_size())));
                return ret;

Another:

                        std::vector<file_slice> files = info.orig_files().map_block(
                                req.piece, req.start, req.length);

                        for (std::vector<file_slice>::iterator i = files.begin();
                                i != files.end(); ++i)
                        {
                                file_slice const& f = *i;
                                if (info.orig_files().pad_file_at(f.file_index))
                                {
                                        m_file_requests.push_back(f.file_index);
                                        continue;
                                }
(...)
                                        std::string path = info.orig_files().file_path(f.file_index);
(...)

I hope you can see what I mean...

@naikel commented on GitHub (Jan 19, 2016): I'll elaborate a little more since just for the purposes of documentation. #2885 was implemented like this: ``` C++ std::vector<libtorrent::file_slice> files( nativeInfo()->map_block(pieceIndex, 0, nativeInfo()->piece_length())); QStringList res; for (const libtorrent::file_slice& s: files) { res.append(filePath(s.file_index)); } return res; ``` And a couple of examples in libtorrent of this kind of code: ``` C++ std::vector<file_slice> files = fs.map_block( p.piece_index, offset, (std::min)(piece_size - offset, int(block_size()))); int ret = 0; for (std::vector<file_slice>::iterator i = files.begin() , end(files.end()); i != end; ++i) { if (fs.pad_file_at(i->file_index)) continue; ret += i->size; } TORRENT_ASSERT(ret <= (std::min)(piece_size - offset, int(block_size()))); return ret; ``` Another: ``` C++ std::vector<file_slice> files = info.orig_files().map_block( req.piece, req.start, req.length); for (std::vector<file_slice>::iterator i = files.begin(); i != files.end(); ++i) { file_slice const& f = *i; if (info.orig_files().pad_file_at(f.file_index)) { m_file_requests.push_back(f.file_index); continue; } (...) std::string path = info.orig_files().file_path(f.file_index); (...) ``` I hope you can see what I mean...
Author
Owner

@sledgehammer999 commented on GitHub (Jan 19, 2016):

@naikel good find. Let's wait a bit for @arvidn to maybe confirm yours if he's willing to take a look.
FYI, "padding files" is an invention of BitComet. It creates dummy files that take the remaining size of the last piece of a file, when that last piece will extend to the next file normally. It is a way to have aligned(?) files. Shitty invention that pollutes the filesystem with useless files.
If you're correct then the users have some torrent in their queue created by BitComet with padding files.

@sledgehammer999 commented on GitHub (Jan 19, 2016): @naikel good find. Let's wait a bit for @arvidn to maybe confirm yours if he's willing to take a look. FYI, "padding files" is an invention of BitComet. It creates dummy files that take the remaining size of the last piece of a file, when that last piece will extend to the next file normally. It is a way to have aligned(?) files. Shitty invention that pollutes the filesystem with useless files. If you're correct then the users have some torrent in their queue created by BitComet with padding files.
Author
Owner

@Nemo-qB commented on GitHub (Jan 19, 2016):

Now you have changed the issue name; thats exactly where it has crashed. I was looking at the peers at that moment when it suddenly happened. I had only 1 torrent (total) running created by uTorrent.

@Nemo-qB commented on GitHub (Jan 19, 2016): Now you have changed the issue name; thats exactly where it has crashed. I was looking at the peers at that moment when it suddenly happened. I had only 1 torrent (total) running created by uTorrent.
Author
Owner

@sledgehammer999 commented on GitHub (Jan 19, 2016):

I had only 1 torrent (total) running created by uTorrent.

Is it reproducible with that? Can you share it? (or email it to me sledgehammer999 (at) qbittorrent (dot) org)

@sledgehammer999 commented on GitHub (Jan 19, 2016): > I had only 1 torrent (total) running created by uTorrent. Is it reproducible with that? Can you share it? (or email it to me sledgehammer999 (at) qbittorrent (dot) org)
Author
Owner

@Nemo-qB commented on GitHub (Jan 19, 2016):

I will try to reproduce the crash, I will also try to reproduce it with different torrents. Give me a few minutes, will edit this post when im done.

Edit 1:
It seems that the new column sometimes shows empty space for a moment instead of the filename while downloading from the peer, not sure if this is intented like this (also not sure if it has something to do with the crash). The filename dissappears and comes back afterwards. The places with the red line are empty, see screenshot:

qbit1

The same torrent that was chrashed is going good for 10 minutes. Weird. I will try a different torrent now.

Edit 2:
Second torrent didn't crashed also. Now I will try to find a torrent that is created by Bitcomet that has padding files (if I can find a healty one).

Edit 3:
It seems that qBittorrent doesn't download the Bitcomet padding files automaticly, ''No downloaded'' it says:

qbit2

The torrent is created by Bitcomet 1.35, running for few minutes now without crash. Choosing the padding files to download shows them 100% right away.

I can't seem to reproduce this crash after my tests. I have to go to sleep now, will try to help further if needed.

@Nemo-qB commented on GitHub (Jan 19, 2016): I will try to reproduce the crash, I will also try to reproduce it with different torrents. Give me a few minutes, will edit this post when im done. Edit 1: It seems that the new column sometimes shows empty space for a moment instead of the filename while downloading from the peer, not sure if this is intented like this (also not sure if it has something to do with the crash). The filename dissappears and comes back afterwards. The places with the red line are empty, see screenshot: ![qbit1](https://cloud.githubusercontent.com/assets/6442930/12435611/db42edd0-bf0e-11e5-891b-4cd664707608.png) The same torrent that was chrashed is going good for 10 minutes. Weird. I will try a different torrent now. Edit 2: Second torrent didn't crashed also. Now I will try to find a torrent that is created by Bitcomet that has padding files (if I can find a healty one). Edit 3: It seems that qBittorrent doesn't download the Bitcomet padding files automaticly, ''No downloaded'' it says: ![qbit2](https://cloud.githubusercontent.com/assets/6442930/12436007/b255892a-bf11-11e5-8d56-20b7fb579be2.png) The torrent is created by Bitcomet 1.35, running for few minutes now without crash. Choosing the padding files to download shows them 100% right away. I can't seem to reproduce this crash after my tests. I have to go to sleep now, will try to help further if needed.
Author
Owner

@arvidn commented on GitHub (Jan 19, 2016):

@sledgehammer999 do you mean torrent_info::file_at()? Yes, the index is the file index. which is in the range [0, num_files).

speaking of padding files, I think they make a lot of sense. They only pollute the filesystem if your client doesn't support them (so they are backwards compatible) and if the creator of the torrent had poor quality (and places the padding files in places to they maximize their pollution, e.g. bitcomet). However, they enable features that should have been supported from the start. specifically:

  1. improved alignment of network buffers and disk clusters
  2. composition and splicing/editing of torrents without costly re-hashing

The latter is important to the internet archive (archive.org).

@arvidn commented on GitHub (Jan 19, 2016): @sledgehammer999 do you mean `torrent_info::file_at()`? Yes, the index is the file index. which is in the range [0, num_files). speaking of padding files, I think they make a lot of sense. They only pollute the filesystem if your client doesn't support them (so they are backwards compatible) and if the creator of the torrent had poor quality (and places the padding files in places to they maximize their pollution, e.g. bitcomet). However, they enable features that should have been supported from the start. specifically: 1. improved alignment of network buffers and disk clusters 2. composition and splicing/editing of torrents without costly re-hashing The latter is important to the internet archive (archive.org).
Author
Owner

@sledgehammer999 commented on GitHub (Jan 19, 2016):

Ok. I see your reasoning. Do you think pad files have something to do with our crashes? -I can't reproduce them-

@sledgehammer999 commented on GitHub (Jan 19, 2016): Ok. I see your reasoning. Do you think pad files have something to do with our crashes? -I can't reproduce them-
Author
Owner

@zeule commented on GitHub (Jan 19, 2016):

@arvidn , can we call file_storage::file_path() with any index, returned by torrent_info::file_at(), or should we exclude pad files?

@zeule commented on GitHub (Jan 19, 2016): @arvidn , can we call `file_storage::file_path()` with any index, returned by `torrent_info::file_at()`, or should we exclude pad files?
Author
Owner

@arvidn commented on GitHub (Jan 19, 2016):

torrent_info::file_at() is a deprecated function that's meant to be replaced by torrent_info::files().xxx() where xxx is individual accessors for various properties of a file. torrent_info::file_at() returns a struct with all properties of a file (that are kept internally). It doesn't return an index as far as I know. The reason for this change is that it gives the implementation a lot more freedom to store the information in more efficient ways.

pad files also have indices assigned to them. the index is literally the index the file entry appears in the .torrent file. (or more precisely, the index into the "files" list in the meta data section of the torrent file, or 0 for single file torrents)

@arvidn commented on GitHub (Jan 19, 2016): `torrent_info::file_at()` is a deprecated function that's meant to be replaced by `torrent_info::files().xxx()` where xxx is individual accessors for various properties of a file. `torrent_info::file_at()` returns a struct with all properties of a file (that are kept internally). It doesn't return an index as far as I know. The reason for this change is that it gives the implementation a lot more freedom to store the information in more efficient ways. pad files also have indices assigned to them. the index is literally the index the file entry appears in the .torrent file. (or more precisely, the index into the "files" list in the meta data section of the torrent file, or 0 for single file torrents)
Author
Owner

@zeule commented on GitHub (Jan 19, 2016):

Thank you

@zeule commented on GitHub (Jan 19, 2016): Thank you
Author
Owner

@naikel commented on GitHub (Jan 19, 2016):

Well I'm not sure if that explains the crash...? It happens because there's some index of a file that doesn't have a name. So when this line from file_path is called:

                return combine_path(save_path
                        , combine_path(m_name
                        , combine_path(m_paths[fe.path_index]
                        , fe.filename())));

It crashes in fe.filename() because it calls std::string(name, name_len) with name being an invalid pointer, and I think that only happens when the index is a pad file.

@naikel commented on GitHub (Jan 19, 2016): Well I'm not sure if that explains the crash...? It happens because there's some index of a file that doesn't have a name. So when this line from file_path is called: ``` C++ return combine_path(save_path , combine_path(m_name , combine_path(m_paths[fe.path_index] , fe.filename()))); ``` It crashes in fe.filename() because it calls std::string(name, name_len) with name being an invalid pointer, and I think that only happens when the index is a pad file.
Author
Owner

@arvidn commented on GitHub (Jan 19, 2016):

filename() (if the file hasn't been renamed) is supposed to point into the metadata buffer. One potential problem is if the file_storage or torrent_info objects have moved, perhaps this pointer hasn't been updated to move with it?

@arvidn commented on GitHub (Jan 19, 2016): filename() (if the file hasn't been renamed) is supposed to point into the metadata buffer. One potential problem is if the file_storage or torrent_info objects have moved, perhaps this pointer hasn't been updated to move with it?
Author
Owner

@arvidn commented on GitHub (Jan 19, 2016):

I think it's an immutable buffer held by a shared_ptr<> though, so that shouldn't be a problem

@arvidn commented on GitHub (Jan 19, 2016): I think it's an immutable buffer held by a shared_ptr<> though, so that shouldn't be a problem
Author
Owner

@naikel commented on GitHub (Jan 19, 2016):

Ok, a more direct question:

Can you call libtorrent::file_path with an index of a pad file? Because in every single line in libtorrent where you call the method file_path, you validate if pad_file_at(index) is false first, even in storage::initialize(), so that's why I think pad files don't have a file_path, and hence the crash when the developer who implemented this tried to do it.

@naikel commented on GitHub (Jan 19, 2016): Ok, a more direct question: Can you call libtorrent::file_path with an index of a pad file? Because in every single line in libtorrent where you call the method file_path, you validate if pad_file_at(index) is false first, even in storage::initialize(), so that's why I think pad files don't have a file_path, and hence the crash when the developer who implemented this tried to do it.
Author
Owner

@arvidn commented on GitHub (Jan 19, 2016):

examples/dump_torrent.cpp calls file_path() for every file, including padfiles.

have you ruled out that the index is out-of-range? the check that's there is only enabled in debug builds.

@arvidn commented on GitHub (Jan 19, 2016): examples/dump_torrent.cpp calls file_path() for every file, including padfiles. have you ruled out that the index is out-of-range? the check that's there is only enabled in debug builds.
Author
Owner

@hdcTenBasePid commented on GitHub (Jan 19, 2016):

I've managed to do it again, but in different circumstances.
Was only seeding, and on a different machine (still 10586.63).
I believe I was looking at the peers, crash, but qBT was still seeding behind the crash report.

Apart from different sequences of dlls (different configuration) the backtrace is identical except for Line #9 from the orginal trace being missing in this one.

qBcrash20160120.1203.txt

@hdcTenBasePid commented on GitHub (Jan 19, 2016): I've managed to do it again, but in different circumstances. Was only seeding, and on a different machine (still 10586.63). I believe I was looking at the peers, crash, but qBT was still seeding behind the crash report. Apart from different sequences of dlls (different configuration) the backtrace is identical except for Line #9 from the orginal trace being missing in this one. [qBcrash20160120.1203.txt](https://github.com/qbittorrent/qBittorrent/files/96923/qBcrash20160120.1203.txt)
Author
Owner

@arvidn commented on GitHub (Jan 19, 2016):

where does the torrent_info object come from? I assume it's returned as a shared_ptr<> from the torrent_handle. is it held by a shared_ptr<> or do you take a local copy of it? (I would recommend the former).

There is one other thing I should probably mention. There's a feature in 1.1rc where torrents can be evicted from memory if they stay inactive and stopped for too long, and if they're needed again a client-supplied load function is called that's supposed to read it back in from disk. This feature only applies to torrents that don't have the "pinned" flag in their add_torrent_params (which is set by default). It also should not be enabled if the client has not supplied a load function, so I doubt that this is the case here. However, since we're dealing with a bug, perhaps there's a bug causing this eviction to trigger even though it shouldn't. Asking for the torrent_info() should always load it back in though.

@arvidn commented on GitHub (Jan 19, 2016): where does the torrent_info object come from? I assume it's returned as a shared_ptr<> from the torrent_handle. is it held by a shared_ptr<> or do you take a local copy of it? (I would recommend the former). There is one other thing I should probably mention. There's a feature in 1.1rc where torrents can be evicted from memory if they stay inactive and stopped for too long, and if they're needed again a client-supplied load function is called that's supposed to read it back in from disk. This feature only applies to torrents that don't have the "pinned" flag in their add_torrent_params (which is set by default). It also should not be enabled if the client has not supplied a load function, so I doubt that this is the case here. However, since we're dealing with a bug, perhaps there's a bug causing this eviction to trigger even though it shouldn't. Asking for the torrent_info() should always load it back in though.
Author
Owner

@glassez commented on GitHub (Jan 20, 2016):

We should check the arguments. At least, (s.file_index >= 0) && (s.file_index < filesCount()).

    std::vector<libtorrent::file_slice> files(
        nativeInfo()->map_block(pieceIndex, 0, nativeInfo()->piece_length()));
    QStringList res;
    for (const libtorrent::file_slice& s: files) {
        res.append(filePath(s.file_index)); // BEFORE this
    }
    return res;
@glassez commented on GitHub (Jan 20, 2016): We should check the arguments. At least, `(s.file_index >= 0) && (s.file_index < filesCount())`. ``` c++ std::vector<libtorrent::file_slice> files( nativeInfo()->map_block(pieceIndex, 0, nativeInfo()->piece_length())); QStringList res; for (const libtorrent::file_slice& s: files) { res.append(filePath(s.file_index)); // BEFORE this } return res; ```
Author
Owner

@zeule commented on GitHub (Jan 20, 2016):

@glassez , do you mean a bug in map_block() or that pieceIndex is out of range?

@zeule commented on GitHub (Jan 20, 2016): @glassez , do you mean a bug in `map_block()` or that `pieceIndex` is out of range?
Author
Owner

@glassez commented on GitHub (Jan 20, 2016):

Anything can happen... We can, at least, check it out.
The question is, can someone from the developers to reproduce this bug. If Yes, then you can simply output a debug message with these values. If not, then it is more difficult. How to make a normal user able to get this information and pass it here?

@glassez commented on GitHub (Jan 20, 2016): Anything can happen... We can, at least, check it out. The question is, can someone from the developers to reproduce this bug. If Yes, then you can simply output a debug message with these values. If not, then it is more difficult. How to make a normal user able to get this information and pass it here?
Author
Owner

@zeule commented on GitHub (Jan 20, 2016):

Then we need a logging.

@zeule commented on GitHub (Jan 20, 2016): Then we need a logging.
Author
Owner

@naikel commented on GitHub (Jan 20, 2016):

What we need is a torrent file that caused this to try to reproduce it.

@naikel commented on GitHub (Jan 20, 2016): What we need is a torrent file that caused this to try to reproduce it.
Author
Owner

@Nemo-qB commented on GitHub (Jan 20, 2016):

I've tried to reproduce the crash, even with a Bitcomet created torrent file with padding files with no succes. See here: https://github.com/qbittorrent/qBittorrent/issues/4597#issuecomment-173022274

@Nemo-qB commented on GitHub (Jan 20, 2016): I've tried to reproduce the crash, even with a Bitcomet created torrent file with padding files with no succes. See here: https://github.com/qbittorrent/qBittorrent/issues/4597#issuecomment-173022274
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

@Nemo-qB FYI when you edit your post no one is notified.
There doesn't seem to be anyone from the devs that is able to reproduce it. So I am thinking of going ahead and implement the range check and release a v3.3.3 ASAP.

@sledgehammer999 commented on GitHub (Jan 20, 2016): @Nemo-qB FYI when you edit your post no one is notified. There doesn't seem to be anyone from the devs that is able to reproduce it. So I am thinking of going ahead and implement the range check and release a v3.3.3 ASAP.
Author
Owner

@glassez commented on GitHub (Jan 20, 2016):

What we need is a torrent file that caused this to try to reproduce it.

+1 if this is a problem of any particular file.
In any case, it doesn't always happen. And it's unclear what it depends on...

@glassez commented on GitHub (Jan 20, 2016): > What we need is a torrent file that caused this to try to reproduce it. +1 if this is a problem of any particular file. In any case, it doesn't always happen. And it's unclear what it depends on...
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

I just closed a few duplicates. 2 people seem to be able to reproduce. I asked them to post or email the offending torrent. Let's see what happens.

@sledgehammer999 commented on GitHub (Jan 20, 2016): I just closed a few duplicates. 2 people seem to be able to reproduce. I asked them to post or email the offending torrent. Let's see what happens.
Author
Owner

@zeule commented on GitHub (Jan 20, 2016):

I would also check that pieceIndex < torrent_info::num_pieces()

@zeule commented on GitHub (Jan 20, 2016): I would also check that `pieceIndex < torrent_info::num_pieces()`
Author
Owner

@glassez commented on GitHub (Jan 20, 2016):

I would also check that pieceIndex < torrent_info::num_pieces()

Yes. And also pieceIndex >= 0
We can't be sure of any of the values involved here.

@glassez commented on GitHub (Jan 20, 2016): > I would also check that `pieceIndex < torrent_info::num_pieces()` Yes. And also `pieceIndex >= 0` We can't be sure of any of the values involved here.
Author
Owner

@ccloli commented on GitHub (Jan 20, 2016):

Here is a torrent that crashed qBittorrent when I opened an issue 4 hours ago. It's still downloading, but when I clicked the "Peers" button, qBittorrent doesn't crash and works fine now. Maybe some
particular peer information crash qBittorrent, but I'm not sure and I can't reproduce it right now. BTW, showing peers on network interface doesn't crash it.

Magnet Link: magnet:?xt=urn:btih:1097c2db007b3b05f5c9a7afa25c8319e874de3e
NOTICE: This torrent contains ADULT content, I'm sorry that it may trouble you.

It seems that the torrent is not created by BitComet, because I don't see the padding files. And when I added it to qBittorrent, it doesn't contain any tracker, but now it has some trackers (I enabled Exchange trackers with other peers on setting).

I also uploaded the torrent file here: http://tempsend.com/D8C6B01A78

@ccloli commented on GitHub (Jan 20, 2016): Here is a torrent that crashed qBittorrent when I opened an issue 4 hours ago. It's still downloading, but when I clicked the "Peers" button, qBittorrent doesn't crash and works fine now. Maybe some particular peer information crash qBittorrent, but I'm not sure and I can't reproduce it right now. BTW, showing peers on network interface doesn't crash it. Magnet Link: magnet:?xt=urn:btih:1097c2db007b3b05f5c9a7afa25c8319e874de3e NOTICE: This torrent contains ADULT content, I'm sorry that it may trouble you. It seems that the torrent is not created by BitComet, because I don't see the padding files. And when I added it to qBittorrent, it doesn't contain any tracker, but now it has some trackers (I enabled _Exchange trackers with other peers_ on setting). I also uploaded the torrent file here: http://tempsend.com/D8C6B01A78
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

An interesting attribute of your torrent is that the filenames have asian characters. So maybe the actual problem is incorrect utf8 handling by libtorrent/qbittorrent. Did anyone that had a crash also have torrents with non-english characters in the filenames?

@sledgehammer999 commented on GitHub (Jan 20, 2016): An interesting attribute of your torrent is that the filenames have asian characters. So maybe the actual problem is incorrect utf8 handling by libtorrent/qbittorrent. Did anyone that had a crash also have torrents with non-english characters in the filenames?
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

This might be a string problem indeed. I can get it to crash with that torrent after a while. Here is some clipped output from the debugger:

0:000> |* ~* kp

.  0  Id: 20ec.2f68 Suspend: 1 Teb: 7efdd000 Unfrozen
ChildEBP RetAddr  
0034d17c 0135c9b0 qbittorrent!memcpy(unsigned char * dst = 0xbaadf00d "--- memory read error at address 0xbaadf00d ---", unsigned char * src = 0x00000aad "--- memory read error at address 0x00000aad ---", unsigned long count = 0x34d290)+0x250 [f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm @ 319]
(Inline) -------- qbittorrent!std::char_traits<char>::copy+0xc [c:\program files (x86)\microsoft visual studio 14.0\vc\include\iosfwd @ 530]
0034d19c 019f8372 qbittorrent!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign(char * _Ptr = 0xbaadf00d "--- memory read error at address 0xbaadf00d ---", unsigned int _Count = 0x9d78558)+0x5a [c:\program files (x86)\microsoft visual studio 14.0\vc\include\xstring @ 1167]
(Inline) -------- qbittorrent!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::{ctor}+0x5d [c:\program files (x86)\microsoft visual studio 14.0\vc\include\xstring @ 812]
0034d1b8 019f81c5 qbittorrent!libtorrent::internal_file_entry::filename(void)+0xb2 [g:\qbittorrent\libtorrent\src\file_storage.cpp @ 234]
0034d264 0138c9b8 qbittorrent!libtorrent::file_storage::file_path(int index = 0n351, class std::basic_string<char,std::char_traits<char>,std::allocator<char> > * save_path = 0x0034d2a8)+0xc5 [g:\qbittorrent\libtorrent\src\file_storage.cpp @ 575]
0034d2d0 0138cdfa qbittorrent!BitTorrent::TorrentInfo::filePath(int index = 0n351)+0x4d [g:\qbittorrent\qbittorrent-3.3.2\src\base\bittorrent\torrentinfo.cpp @ 150]
0034d318 013cfb94 qbittorrent!BitTorrent::TorrentInfo::filesForPiece(int pieceIndex = <Value unavailable error>)+0x9c [g:\qbittorrent\qbittorrent-3.3.2\src\base\bittorrent\torrentinfo.cpp @ 223]
0034d394 013ce92e qbittorrent!PeerListWidget::updatePeer(class QString * ip = 0x05436048, class BitTorrent::TorrentHandle * torrent = 0x03dd8ef8, class BitTorrent::PeerInfo * peer = <Value unavailable error>)+0x6b5 [g:\qbittorrent\qbittorrent-3.3.2\src\gui\properties\peerlistwidget.cpp @ 372]
0034d3f0 013c9522 qbittorrent!PeerListWidget::loadPeers(class BitTorrent::TorrentHandle * torrent = 0x03dd8ef8, bool forceHostnameResolution = false)+0xeb [g:\qbittorrent\qbittorrent-3.3.2\src\gui\properties\peerlistwidget.cpp @ 287]
0034d560 01433c40 qbittorrent!PropertiesWidget::loadDynamicData(void)+0xf3 [g:\qbittorrent\qbittorrent-3.3.2\src\gui\properties\propertieswidget.cpp @ 471]
0034d570 017f18db qbittorrent!PropertiesWidget::qt_static_metacall(class QObject * _o = 0x05747098, QMetaObject::Call _c = InvokeMetaMethod (0n0), int _id = 0n15, void ** _a = 0x0034d600)+0x13d [g:\qbittorrent\build-qbittorrent-332\src\release\moc_propertieswidget.cpp @ 172]
0034d618 017f147f qbittorrent!QMetaObject::activate+0x455
0034d630 01862455 qbittorrent!QMetaObject::activate+0x20
0034d63c 01814a77 qbittorrent!QTimer::timeout+0xe
0034d64c 017eec70 qbittorrent!QTimer::timerEvent+0x26
0034d694 014c7b75 qbittorrent!QObject::event+0x191
0034d6b0 014c769c qbittorrent!QApplicationPrivate::notify_helper+0x9b
0034dae4 01357d71 qbittorrent!QApplication::notify+0x15b2
0034db2c 01811ce0 qbittorrent!Application::notify(class QObject * receiver = 0x05839a88, class QEvent * event = 0x0034db98)+0x1b [g:\qbittorrent\qbittorrent-3.3.2\src\app\application.cpp @ 337]
0034db74 014ca1ca qbittorrent!QCoreApplication::notifyInternal+0x55
0034db80 018a42f9 qbittorrent!QCoreApplication::sendEvent+0x1d
0034dbb4 018a3d6a qbittorrent!QEventDispatcherWin32Private::sendTimerEvent+0x54
0034dc18 75a662fa qbittorrent!qt_internal_proc+0x1c1
0034dc44 75a66d3a USER32!InternalCallWinProc+0x23
0034dcbc 75a677c4 USER32!UserCallWinProcCheckWow+0x109
0034dd1c 75a6788a USER32!DispatchMessageWorker+0x3bc
0034dd2c 018a4899 USER32!DispatchMessageW+0xf
0034fae4 018f31d1 qbittorrent!QEventDispatcherWin32::processEvents+0x41a
0034fb24 0187a214 qbittorrent!QWindowsGuiEventDispatcher::processEvents+0xe0
0034fb74 01811fec qbittorrent!QEventLoop::exec+0x143
0034fbbc 01357ba2 qbittorrent!QCoreApplication::exec+0xe6
0034fbe8 0135bad8 qbittorrent!Application::exec(class QStringList * params = 0x0034fc0c)+0x285 [g:\qbittorrent\qbittorrent-3.3.2\src\app\application.cpp @ 283]
0034fc48 0198d535 qbittorrent!main(int argc = 0n1, char ** argv = <Value unavailable error>)+0x26f [g:\qbittorrent\qbittorrent-3.3.2\src\app\main.cpp @ 249]
0034fc74 01b0fd49 qbittorrent!WinMain+0xc7
(Inline) -------- qbittorrent!invoke_main+0x1a [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 104]
0034fcc0 75b833aa qbittorrent!__scrt_common_main_seh(void)+0xfd [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264]
0034fccc 77cc9f72 kernel32!BaseThreadInitThunk+0xe
0034fd0c 77cc9f45 ntdll!__RtlUserThreadStart+0x70
0034fd24 00000000 ntdll!_RtlUserThreadStart+0x1b

....
....

0:000> |* !analyze -v -f
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
qbittorrent!memcpy+250 [f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm @ 319]
01b11c00 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 01b11c00 (qbittorrent!memcpy+0x00000250)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: baadf00d
Attempt to read from address baadf00d

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=b37a7555 ebx=baadf00d ecx=000002ab edx=00000aad esi=baadf00d edi=09d78558
eip=01b11c00 esp=0034d178 ebp=0034d19c iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010212
qbittorrent!memcpy+0x250:
01b11c00 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

FAULTING_THREAD:  00002f68

DEFAULT_BUCKET_ID:  STRING_DEREFERENCE

PROCESS_NAME:  qbittorrent.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  baadf00d

READ_ADDRESS:  baadf00d 

FOLLOWUP_IP: 
qbittorrent!memcpy+250 [f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm @ 319]
01b11c00 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

NTGLOBALFLAG:  70

APPLICATION_VERIFIER_FLAGS:  0

APP:  qbittorrent.exe

ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre

PRIMARY_PROBLEM_CLASS:  STRING_DEREFERENCE

BUGCHECK_STR:  APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 0135c9b0 to 01b11c00

STACK_TEXT:  
0034d17c 0135c9b0 09d78558 baadf00d 00000aad qbittorrent!memcpy+0x250
0034d19c 019f8372 baadf00d 00000aad 0034d290 qbittorrent!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign+0x5a
0034d1b8 019f81c5 0034d224 e1ea630c 0034d39c qbittorrent!libtorrent::internal_file_entry::filename+0xb2
0034d264 0138c9b8 0034d290 0000015f 0034d2a8 qbittorrent!libtorrent::file_storage::file_path+0xc5
0034d2d0 0138cdfa 0034d304 0000015f e1ea6270 qbittorrent!BitTorrent::TorrentInfo::filePath+0x4d
0034d318 013cfb94 0034d3a4 098ed4e0 e1ea62fc qbittorrent!BitTorrent::TorrentInfo::filesForPiece+0x9c
0034d394 013ce92e 05436048 03dd8ef8 09720ef8 qbittorrent!PeerListWidget::updatePeer+0x6b5
0034d3f0 013c9522 03dd8ef8 00000000 e1ea6408 qbittorrent!PeerListWidget::loadPeers+0xeb
0034d560 01433c40 05839bf0 0000002f 0034d618 qbittorrent!PropertiesWidget::loadDynamicData+0xf3
0034d570 017f18db 05747098 00000000 0000000f qbittorrent!PropertiesWidget::qt_static_metacall+0x13d
0034d618 017f147f 0000000f 00000000 05839a88 qbittorrent!QMetaObject::activate+0x455
0034d630 01862455 00000000 00000000 01814a77 qbittorrent!QMetaObject::activate+0x20
0034d63c 01814a77 0034db98 05839a88 0034d694 qbittorrent!QTimer::timeout+0xe
0034d64c 017eec70 0034db98 e1ea67fc 05839a88 qbittorrent!QTimer::timerEvent+0x26
0034d694 014c7b75 0034db98 05839a88 003c3998 qbittorrent!QObject::event+0x191
0034d6b0 014c769c 05839a88 0034db98 05839a88 qbittorrent!QApplicationPrivate::notify_helper+0x9b
0034dae4 01357d71 05839a88 0034db98 e1ea6a44 qbittorrent!QApplication::notify+0x15b2
0034db2c 01811ce0 05839a88 0034db98 e1ea6a1c qbittorrent!Application::notify+0x1b
0034db74 014ca1ca 05839a88 0034db98 018a42f9 qbittorrent!QCoreApplication::notifyInternal+0x55
0034db80 018a42f9 e1ea6adc 003d1488 00000113 qbittorrent!QCoreApplication::sendEvent+0x1d
0034dbb4 018a3d6a 00000014 e1ea6d70 00000000 qbittorrent!QEventDispatcherWin32Private::sendTimerEvent+0x54
0034dc18 75a662fa 025b04e8 00000113 00000014 qbittorrent!qt_internal_proc+0x1c1
0034dc44 75a66d3a 018a3ba9 025b04e8 00000113 USER32!InternalCallWinProc+0x23
0034dcbc 75a677c4 00000000 018a3ba9 025b04e8 USER32!UserCallWinProcCheckWow+0x109
0034dd1c 75a6788a 018a3ba9 00000000 0034fae4 USER32!DispatchMessageWorker+0x3bc
0034dd2c 018a4899 0034f9ac e1ea4b8c 003c4720 USER32!DispatchMessageW+0xf
0034fae4 018f31d1 00000024 0034fba4 056e4540 qbittorrent!QEventDispatcherWin32::processEvents+0x41a
0034fb24 0187a214 00000024 e1ea4a1c 003c38c0 qbittorrent!QWindowsGuiEventDispatcher::processEvents+0xe0
0034fb74 01811fec 00000000 e1ea4ad4 003c38c0 qbittorrent!QEventLoop::exec+0x143
0034fbbc 01357ba2 e1ea4a80 00000000 003c38c0 qbittorrent!QCoreApplication::exec+0xe6
0034fbe8 0135bad8 0034fc0c e1ea4d20 003c3738 qbittorrent!Application::exec+0x285
0034fc48 0198d535 021f27b0 7efde000 00000000 qbittorrent!main+0x26f
0034fc74 01b0fd49 01330000 00000000 00375314 qbittorrent!WinMain+0xc7
0034fcc0 75b833aa 7efde000 0034fd0c 77cc9f72 qbittorrent!__scrt_common_main_seh+0xfd
0034fccc 77cc9f72 7efde000 58186694 00000000 kernel32!BaseThreadInitThunk+0xe
0034fd0c 77cc9f45 01b0fdc2 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
0034fd24 00000000 01b0fdc2 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  .cxr 0x0 ; kb

FAULTING_SOURCE_LINE:  f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm

FAULTING_SOURCE_FILE:  f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm

FAULTING_SOURCE_LINE_NUMBER:  319

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  qbittorrent!memcpy+250

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: qbittorrent

IMAGE_NAME:  qbittorrent.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  569d7fbb

FAILURE_BUCKET_ID:  STRING_DEREFERENCE_c0000005_qbittorrent.exe!memcpy

BUCKET_ID:  APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_READ_qbittorrent!memcpy+250

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:string_dereference_c0000005_qbittorrent.exe!memcpy
@sledgehammer999 commented on GitHub (Jan 20, 2016): This might be a string problem indeed. I can get it to crash with that torrent after a while. Here is some clipped output from the debugger: ``` 0:000> |* ~* kp . 0 Id: 20ec.2f68 Suspend: 1 Teb: 7efdd000 Unfrozen ChildEBP RetAddr 0034d17c 0135c9b0 qbittorrent!memcpy(unsigned char * dst = 0xbaadf00d "--- memory read error at address 0xbaadf00d ---", unsigned char * src = 0x00000aad "--- memory read error at address 0x00000aad ---", unsigned long count = 0x34d290)+0x250 [f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm @ 319] (Inline) -------- qbittorrent!std::char_traits<char>::copy+0xc [c:\program files (x86)\microsoft visual studio 14.0\vc\include\iosfwd @ 530] 0034d19c 019f8372 qbittorrent!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign(char * _Ptr = 0xbaadf00d "--- memory read error at address 0xbaadf00d ---", unsigned int _Count = 0x9d78558)+0x5a [c:\program files (x86)\microsoft visual studio 14.0\vc\include\xstring @ 1167] (Inline) -------- qbittorrent!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::{ctor}+0x5d [c:\program files (x86)\microsoft visual studio 14.0\vc\include\xstring @ 812] 0034d1b8 019f81c5 qbittorrent!libtorrent::internal_file_entry::filename(void)+0xb2 [g:\qbittorrent\libtorrent\src\file_storage.cpp @ 234] 0034d264 0138c9b8 qbittorrent!libtorrent::file_storage::file_path(int index = 0n351, class std::basic_string<char,std::char_traits<char>,std::allocator<char> > * save_path = 0x0034d2a8)+0xc5 [g:\qbittorrent\libtorrent\src\file_storage.cpp @ 575] 0034d2d0 0138cdfa qbittorrent!BitTorrent::TorrentInfo::filePath(int index = 0n351)+0x4d [g:\qbittorrent\qbittorrent-3.3.2\src\base\bittorrent\torrentinfo.cpp @ 150] 0034d318 013cfb94 qbittorrent!BitTorrent::TorrentInfo::filesForPiece(int pieceIndex = <Value unavailable error>)+0x9c [g:\qbittorrent\qbittorrent-3.3.2\src\base\bittorrent\torrentinfo.cpp @ 223] 0034d394 013ce92e qbittorrent!PeerListWidget::updatePeer(class QString * ip = 0x05436048, class BitTorrent::TorrentHandle * torrent = 0x03dd8ef8, class BitTorrent::PeerInfo * peer = <Value unavailable error>)+0x6b5 [g:\qbittorrent\qbittorrent-3.3.2\src\gui\properties\peerlistwidget.cpp @ 372] 0034d3f0 013c9522 qbittorrent!PeerListWidget::loadPeers(class BitTorrent::TorrentHandle * torrent = 0x03dd8ef8, bool forceHostnameResolution = false)+0xeb [g:\qbittorrent\qbittorrent-3.3.2\src\gui\properties\peerlistwidget.cpp @ 287] 0034d560 01433c40 qbittorrent!PropertiesWidget::loadDynamicData(void)+0xf3 [g:\qbittorrent\qbittorrent-3.3.2\src\gui\properties\propertieswidget.cpp @ 471] 0034d570 017f18db qbittorrent!PropertiesWidget::qt_static_metacall(class QObject * _o = 0x05747098, QMetaObject::Call _c = InvokeMetaMethod (0n0), int _id = 0n15, void ** _a = 0x0034d600)+0x13d [g:\qbittorrent\build-qbittorrent-332\src\release\moc_propertieswidget.cpp @ 172] 0034d618 017f147f qbittorrent!QMetaObject::activate+0x455 0034d630 01862455 qbittorrent!QMetaObject::activate+0x20 0034d63c 01814a77 qbittorrent!QTimer::timeout+0xe 0034d64c 017eec70 qbittorrent!QTimer::timerEvent+0x26 0034d694 014c7b75 qbittorrent!QObject::event+0x191 0034d6b0 014c769c qbittorrent!QApplicationPrivate::notify_helper+0x9b 0034dae4 01357d71 qbittorrent!QApplication::notify+0x15b2 0034db2c 01811ce0 qbittorrent!Application::notify(class QObject * receiver = 0x05839a88, class QEvent * event = 0x0034db98)+0x1b [g:\qbittorrent\qbittorrent-3.3.2\src\app\application.cpp @ 337] 0034db74 014ca1ca qbittorrent!QCoreApplication::notifyInternal+0x55 0034db80 018a42f9 qbittorrent!QCoreApplication::sendEvent+0x1d 0034dbb4 018a3d6a qbittorrent!QEventDispatcherWin32Private::sendTimerEvent+0x54 0034dc18 75a662fa qbittorrent!qt_internal_proc+0x1c1 0034dc44 75a66d3a USER32!InternalCallWinProc+0x23 0034dcbc 75a677c4 USER32!UserCallWinProcCheckWow+0x109 0034dd1c 75a6788a USER32!DispatchMessageWorker+0x3bc 0034dd2c 018a4899 USER32!DispatchMessageW+0xf 0034fae4 018f31d1 qbittorrent!QEventDispatcherWin32::processEvents+0x41a 0034fb24 0187a214 qbittorrent!QWindowsGuiEventDispatcher::processEvents+0xe0 0034fb74 01811fec qbittorrent!QEventLoop::exec+0x143 0034fbbc 01357ba2 qbittorrent!QCoreApplication::exec+0xe6 0034fbe8 0135bad8 qbittorrent!Application::exec(class QStringList * params = 0x0034fc0c)+0x285 [g:\qbittorrent\qbittorrent-3.3.2\src\app\application.cpp @ 283] 0034fc48 0198d535 qbittorrent!main(int argc = 0n1, char ** argv = <Value unavailable error>)+0x26f [g:\qbittorrent\qbittorrent-3.3.2\src\app\main.cpp @ 249] 0034fc74 01b0fd49 qbittorrent!WinMain+0xc7 (Inline) -------- qbittorrent!invoke_main+0x1a [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 104] 0034fcc0 75b833aa qbittorrent!__scrt_common_main_seh(void)+0xfd [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264] 0034fccc 77cc9f72 kernel32!BaseThreadInitThunk+0xe 0034fd0c 77cc9f45 ntdll!__RtlUserThreadStart+0x70 0034fd24 00000000 ntdll!_RtlUserThreadStart+0x1b .... .... 0:000> |* !analyze -v -f ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* FAULTING_IP: qbittorrent!memcpy+250 [f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm @ 319] 01b11c00 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 01b11c00 (qbittorrent!memcpy+0x00000250) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: baadf00d Attempt to read from address baadf00d CONTEXT: 00000000 -- (.cxr 0x0;r) eax=b37a7555 ebx=baadf00d ecx=000002ab edx=00000aad esi=baadf00d edi=09d78558 eip=01b11c00 esp=0034d178 ebp=0034d19c iopl=0 nv up ei pl nz ac po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010212 qbittorrent!memcpy+0x250: 01b11c00 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] FAULTING_THREAD: 00002f68 DEFAULT_BUCKET_ID: STRING_DEREFERENCE PROCESS_NAME: qbittorrent.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000000 EXCEPTION_PARAMETER2: baadf00d READ_ADDRESS: baadf00d FOLLOWUP_IP: qbittorrent!memcpy+250 [f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm @ 319] 01b11c00 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] NTGLOBALFLAG: 70 APPLICATION_VERIFIER_FLAGS: 0 APP: qbittorrent.exe ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre PRIMARY_PROBLEM_CLASS: STRING_DEREFERENCE BUGCHECK_STR: APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_READ LAST_CONTROL_TRANSFER: from 0135c9b0 to 01b11c00 STACK_TEXT: 0034d17c 0135c9b0 09d78558 baadf00d 00000aad qbittorrent!memcpy+0x250 0034d19c 019f8372 baadf00d 00000aad 0034d290 qbittorrent!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign+0x5a 0034d1b8 019f81c5 0034d224 e1ea630c 0034d39c qbittorrent!libtorrent::internal_file_entry::filename+0xb2 0034d264 0138c9b8 0034d290 0000015f 0034d2a8 qbittorrent!libtorrent::file_storage::file_path+0xc5 0034d2d0 0138cdfa 0034d304 0000015f e1ea6270 qbittorrent!BitTorrent::TorrentInfo::filePath+0x4d 0034d318 013cfb94 0034d3a4 098ed4e0 e1ea62fc qbittorrent!BitTorrent::TorrentInfo::filesForPiece+0x9c 0034d394 013ce92e 05436048 03dd8ef8 09720ef8 qbittorrent!PeerListWidget::updatePeer+0x6b5 0034d3f0 013c9522 03dd8ef8 00000000 e1ea6408 qbittorrent!PeerListWidget::loadPeers+0xeb 0034d560 01433c40 05839bf0 0000002f 0034d618 qbittorrent!PropertiesWidget::loadDynamicData+0xf3 0034d570 017f18db 05747098 00000000 0000000f qbittorrent!PropertiesWidget::qt_static_metacall+0x13d 0034d618 017f147f 0000000f 00000000 05839a88 qbittorrent!QMetaObject::activate+0x455 0034d630 01862455 00000000 00000000 01814a77 qbittorrent!QMetaObject::activate+0x20 0034d63c 01814a77 0034db98 05839a88 0034d694 qbittorrent!QTimer::timeout+0xe 0034d64c 017eec70 0034db98 e1ea67fc 05839a88 qbittorrent!QTimer::timerEvent+0x26 0034d694 014c7b75 0034db98 05839a88 003c3998 qbittorrent!QObject::event+0x191 0034d6b0 014c769c 05839a88 0034db98 05839a88 qbittorrent!QApplicationPrivate::notify_helper+0x9b 0034dae4 01357d71 05839a88 0034db98 e1ea6a44 qbittorrent!QApplication::notify+0x15b2 0034db2c 01811ce0 05839a88 0034db98 e1ea6a1c qbittorrent!Application::notify+0x1b 0034db74 014ca1ca 05839a88 0034db98 018a42f9 qbittorrent!QCoreApplication::notifyInternal+0x55 0034db80 018a42f9 e1ea6adc 003d1488 00000113 qbittorrent!QCoreApplication::sendEvent+0x1d 0034dbb4 018a3d6a 00000014 e1ea6d70 00000000 qbittorrent!QEventDispatcherWin32Private::sendTimerEvent+0x54 0034dc18 75a662fa 025b04e8 00000113 00000014 qbittorrent!qt_internal_proc+0x1c1 0034dc44 75a66d3a 018a3ba9 025b04e8 00000113 USER32!InternalCallWinProc+0x23 0034dcbc 75a677c4 00000000 018a3ba9 025b04e8 USER32!UserCallWinProcCheckWow+0x109 0034dd1c 75a6788a 018a3ba9 00000000 0034fae4 USER32!DispatchMessageWorker+0x3bc 0034dd2c 018a4899 0034f9ac e1ea4b8c 003c4720 USER32!DispatchMessageW+0xf 0034fae4 018f31d1 00000024 0034fba4 056e4540 qbittorrent!QEventDispatcherWin32::processEvents+0x41a 0034fb24 0187a214 00000024 e1ea4a1c 003c38c0 qbittorrent!QWindowsGuiEventDispatcher::processEvents+0xe0 0034fb74 01811fec 00000000 e1ea4ad4 003c38c0 qbittorrent!QEventLoop::exec+0x143 0034fbbc 01357ba2 e1ea4a80 00000000 003c38c0 qbittorrent!QCoreApplication::exec+0xe6 0034fbe8 0135bad8 0034fc0c e1ea4d20 003c3738 qbittorrent!Application::exec+0x285 0034fc48 0198d535 021f27b0 7efde000 00000000 qbittorrent!main+0x26f 0034fc74 01b0fd49 01330000 00000000 00375314 qbittorrent!WinMain+0xc7 0034fcc0 75b833aa 7efde000 0034fd0c 77cc9f72 qbittorrent!__scrt_common_main_seh+0xfd 0034fccc 77cc9f72 7efde000 58186694 00000000 kernel32!BaseThreadInitThunk+0xe 0034fd0c 77cc9f45 01b0fdc2 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70 0034fd24 00000000 01b0fdc2 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b STACK_COMMAND: .cxr 0x0 ; kb FAULTING_SOURCE_LINE: f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm FAULTING_SOURCE_FILE: f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm FAULTING_SOURCE_LINE_NUMBER: 319 SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: qbittorrent!memcpy+250 FOLLOWUP_NAME: MachineOwner MODULE_NAME: qbittorrent IMAGE_NAME: qbittorrent.exe DEBUG_FLR_IMAGE_TIMESTAMP: 569d7fbb FAILURE_BUCKET_ID: STRING_DEREFERENCE_c0000005_qbittorrent.exe!memcpy BUCKET_ID: APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_READ_qbittorrent!memcpy+250 ANALYSIS_SOURCE: UM FAILURE_ID_HASH_STRING: um:string_dereference_c0000005_qbittorrent.exe!memcpy ```
Author
Owner

@naikel commented on GitHub (Jan 20, 2016):

Is this only happening in Windows? I might never reproduce it then 😞

@naikel commented on GitHub (Jan 20, 2016): Is this only happening in Windows? I might never reproduce it then :disappointed:
Author
Owner

@glassez commented on GitHub (Jan 20, 2016):

Here is a torrent that crashed

Bug confirmed with this torrent.

This might be a string problem indeed.

But why now? I mean starting from v3.3.2.

@glassez commented on GitHub (Jan 20, 2016): > Here is a torrent that crashed Bug confirmed with this torrent. > This might be a string problem indeed. But why now? I mean starting from v3.3.2.
Author
Owner

@ccloli commented on GitHub (Jan 20, 2016):

It would probably from the new feature that has been mentioned at https://github.com/qbittorrent/qBittorrent/issues/4597#issuecomment-172794694

FEATURE: Add a new column to peers list that shows list of files which are downloaded right now from a peer. (evsh)
@ccloli commented on GitHub (Jan 20, 2016): It would probably from the new feature that has been mentioned at https://github.com/qbittorrent/qBittorrent/issues/4597#issuecomment-172794694 ``` FEATURE: Add a new column to peers list that shows list of files which are downloaded right now from a peer. (evsh) ```
Author
Owner

@glassez commented on GitHub (Jan 20, 2016):

It would probably from the new feature that has been mentioned at #4597 (comment)

Clear. Another is unclear. It seems that this happens when you access the file name. But these same functions are used everywhere in the program, and not only in this new feature.

@glassez commented on GitHub (Jan 20, 2016): > It would probably from the new feature that has been mentioned at #4597 (comment) Clear. Another is unclear. It seems that this happens when you access the file name. But these same functions are used everywhere in the program, and not only in this new feature.
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

Minor update: I am currently running a custom version what will print "out of bounds" piece index or files index. And now I am waiting for it to crash...

@sledgehammer999 commented on GitHub (Jan 20, 2016): Minor update: I am currently running a custom version what will print "out of bounds" piece index or files index. And now I am waiting for it to crash...
Author
Owner

@hdcTenBasePid commented on GitHub (Jan 20, 2016):

I can see your all making progess. Didn’t even notice the new column in Peers (never maximised screen).

Finally worked out the torrents effective at the crash times. Only included the first Tracker for brevity:

  1. Orginal occurance both down/uploading
  2. Second occurance seeding only

PS: Luv your (the gang) work.

SeedingLeech.10Home.txt
SeedingOnly.10Pro.txt

@hdcTenBasePid commented on GitHub (Jan 20, 2016): I can see your all making progess. Didn’t even notice the new column in Peers (never maximised screen). Finally worked out the torrents effective at the crash times. Only included the first Tracker for brevity: 1. Orginal occurance both down/uploading 2. Second occurance seeding only PS: Luv your (the gang) work. [SeedingLeech.10Home.txt](https://github.com/qbittorrent/qBittorrent/files/97702/SeedingLeech.10Home.txt) [SeedingOnly.10Pro.txt](https://github.com/qbittorrent/qBittorrent/files/97703/SeedingOnly.10Pro.txt)
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

Minor update: I am currently running a custom version what will print "out of bounds" piece index or files index. And now I am waiting for it to crash...

It just crashed. I didn't get any printout of "out of bounds" piece or file index...

@sledgehammer999 commented on GitHub (Jan 20, 2016): Minor update: I am currently running a custom version what will print "out of bounds" piece index or files index. And now I am waiting for it to crash... It just crashed. I didn't get any printout of "out of bounds" piece or file index...
Author
Owner

@naikel commented on GitHub (Jan 20, 2016):

That's kinda bad news, because now you'd have to insert debug lines in libtorrent to see why file_storage::file_path and/or internal_file_entry::filename crash.

So far with that torrent I haven't seen a crash in Linux...

@naikel commented on GitHub (Jan 20, 2016): That's kinda bad news, because now you'd have to insert debug lines in libtorrent to see why file_storage::file_path and/or internal_file_entry::filename crash. So far with that torrent I haven't seen a crash in Linux...
Author
Owner

@glassez commented on GitHub (Jan 20, 2016):

now you'd have to insert debug lines in libtorrent to see why file_storage::file_path and/or internal_file_entry::filename crash.

And, maybe, try to insert try-catch around filePath() call? In catch we can suppres program crash and print some debug info. @sledgehammer999, It will also be useful as workaround to get rid of crashes in future versions, until we find a solution.

@glassez commented on GitHub (Jan 20, 2016): > now you'd have to insert debug lines in libtorrent to see why file_storage::file_path and/or internal_file_entry::filename crash. And, maybe, try to insert `try-catch` around filePath() call? In `catch` we can suppres program crash and print some debug info. @sledgehammer999, It will also be useful as workaround to get rid of crashes in future versions, until we find a solution.
Author
Owner

@asturel commented on GitHub (Jan 20, 2016):

I dont rly see a pattern in torrents what cause crash (none of my torrents had special characters, but they where ~8-16GB), how can I debug the functions values? Just attach the process/start debugging in Qt Creator? Does it requires qbt to be compiled in debug mode?

@asturel commented on GitHub (Jan 20, 2016): I dont rly see a pattern in torrents what cause crash (none of my torrents had special characters, but they where ~8-16GB), how can I debug the functions values? Just attach the process/start debugging in Qt Creator? Does it requires qbt to be compiled in debug mode?
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

It's been one day from release and a lot of crash reports are coming in. I am not confident that I'll find/fix the bug today. And tomorrow I'll be out of town for most of the day. I'll disable temporarily that feature and release v3.3.3.
@glassez if in the meantime you want to continue debugging be my guest.

That's kinda bad news, because now you'd have to insert debug lines in libtorrent to see why file_storage::file_path and/or internal_file_entry::filename crash.

I am thinking of outputting in a txt file the values of the local vars of each function. Do you guys have any better idea?

@sledgehammer999 commented on GitHub (Jan 20, 2016): It's been one day from release and a lot of crash reports are coming in. I am not confident that I'll find/fix the bug today. And tomorrow I'll be out of town for most of the day. I'll disable temporarily that feature and release v3.3.3. @glassez if in the meantime you want to continue debugging be my guest. > That's kinda bad news, because now you'd have to insert debug lines in libtorrent to see why file_storage::file_path and/or internal_file_entry::filename crash. I am thinking of outputting in a txt file the values of the local vars of each function. Do you guys have any better idea?
Author
Owner

@naikel commented on GitHub (Jan 20, 2016):

I'm in no way discouraging anybody or any feature but I wonder how is it useful to know just for an instant of a second what file a peer is downloading a piece? To me it changes very fast and sometimes I can't even read what file was...

@naikel commented on GitHub (Jan 20, 2016): I'm in no way discouraging anybody or any feature but I wonder how is it useful to know just for an instant of a second what file a peer is downloading a piece? To me it changes very fast and sometimes I can't even read what file was...
Author
Owner

@Nemo-qB commented on GitHub (Jan 20, 2016):

+1 to naikel.

@Nemo-qB commented on GitHub (Jan 20, 2016): +1 to naikel.
Author
Owner

@arvidn commented on GitHub (Jan 20, 2016):

from that debugger output:
int _Count = 0x9d78558
that's the length of the string passed in to the std::string constructor. This implies that the internal_file_entry itself is invalid, for whatever reason, not just the string pointer

@arvidn commented on GitHub (Jan 20, 2016): from that debugger output: int _Count = 0x9d78558 that's the length of the string passed in to the std::string constructor. This implies that the internal_file_entry itself is invalid, for whatever reason, not just the string pointer
Author
Owner

@arvidn commented on GitHub (Jan 20, 2016):

is this crash new with libtorrent 1.0.8?

@arvidn commented on GitHub (Jan 20, 2016): is this crash new with libtorrent 1.0.8?
Author
Owner

@naikel commented on GitHub (Jan 20, 2016):

I'm trying to reproduce it in Linux with 1.0.6 and I just can't, but now I don't know if it's Linux or libtorrent 1.0.6 that doesn't have the bug...

@naikel commented on GitHub (Jan 20, 2016): I'm trying to reproduce it in Linux with 1.0.6 and I just can't, but now I don't know if it's Linux or libtorrent 1.0.6 that doesn't have the bug...
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

is this crash new with libtorrent 1.0.8?

I can't tell. Previous qbt version didn't have the offending feature implemented and it used 1.0.7.
As a matter of fact I'll do a test with 1.0.7. It is easy leaving it in the background while doing other stuff.

@sledgehammer999 commented on GitHub (Jan 20, 2016): > is this crash new with libtorrent 1.0.8? I can't tell. Previous qbt version didn't have the offending feature implemented and it used 1.0.7. As a matter of fact I'll do a test with 1.0.7. It is easy leaving it in the background while doing other stuff.
Author
Owner

@glassez commented on GitHub (Jan 20, 2016):

I'm in no way discouraging anybody or any feature but I wonder how is it useful to know just for an instant of a second what file a peer is downloading a piece? To me it changes very fast and sometimes I can't even read what file was...

For me this is also a completely useless thing.

is this crash new with libtorrent 1.0.8?

No. I reproduced this with 1.0.7.

@glassez commented on GitHub (Jan 20, 2016): > I'm in no way discouraging anybody or any feature but I wonder how is it useful to know just for an instant of a second what file a peer is downloading a piece? To me it changes very fast and sometimes I can't even read what file was... For me this is also a completely useless thing. > is this crash new with libtorrent 1.0.8? No. I reproduced this with 1.0.7.
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

No. I reproduced this with 1.0.7.

Phew. You saved me time.

@sledgehammer999 commented on GitHub (Jan 20, 2016): > No. I reproduced this with 1.0.7. Phew. You saved me time.
Author
Owner

@glassez commented on GitHub (Jan 20, 2016):

from that debugger output:
int _Count = 0x9d78558
that's the length of the string passed in to the std::string constructor.

I seen into internal_file_entry code a little. It should limit the string length. If 0x9d78558 is greater than max Len value then it clearly bug there.

@glassez commented on GitHub (Jan 20, 2016): > from that debugger output: > int _Count = 0x9d78558 > that's the length of the string passed in to the std::string constructor. I seen into internal_file_entry code a little. It should limit the string length. If 0x9d78558 is greater than max Len value then it clearly bug there.
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

@naikel I got a crash on Debian sid (libtorrent 1.0.7) with another random torrent:

magnet:?xt=urn:btih:a68d12b8b479a646bd7efae253f98610a5cd74cb&dn=%5bHorribleSubs%5d%20Kono%20Subarashii%20Sekai%20ni%20Shukufuku%20wo!%20-%2002%20%5b720p%5d.mkv&tr=http%3a%2f%2fopen.nyaatorrents.info%3a6544%2fannounce&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce

I don't think it will help but here is gdb bt

Thread 1 (Thread 0x7ffff7e81900 (LWP 3578)):
#0  libtorrent::combine_path (
    lhs=<error reading variable: Cannot access memory at address 0xe4d5799e8>, 
    rhs="") at ../../src/file.cpp:590
#1  0x00007ffff770a5c8 in libtorrent::file_storage::file_path (this=0x100d068, 
    index=index@entry=1, save_path="") at ../../src/file_storage.cpp:581
#2  0x0000000000530934 in BitTorrent::TorrentInfo::filePath (
    this=this@entry=0x7fffffffd400, index=1)
    at base/bittorrent/torrentinfo.cpp:150
#3  0x0000000000531525 in BitTorrent::TorrentInfo::filesForPiece (
    this=this@entry=0x7fffffffd400, pieceIndex=pieceIndex@entry=1286)
    at base/bittorrent/torrentinfo.cpp:223
#4  0x00000000005d4bc3 in PeerListWidget::updatePeer (
    this=this@entry=0xea35e0, ip=..., torrent=torrent@entry=0x1bf3ee0, 
    peer=...) at gui/properties/peerlistwidget.cpp:372
#5  0x00000000005d660a in PeerListWidget::loadPeers (this=0xea35e0, 
    torrent=0x1bf3ee0, 
    forceHostnameResolution=forceHostnameResolution@entry=false)
    at gui/properties/peerlistwidget.cpp:286
#6  0x00000000005c705d in PropertiesWidget::loadDynamicData (this=0xe166f0)
    at gui/properties/propertieswidget.cpp:470
#7  0x00007ffff64f86ca in QMetaObject::activate(QObject*, int, int, void**) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007ffff6504f78 in QTimer::timerEvent(QTimerEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007ffff64f9543 in QObject::event(QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007ffff6f14ffc in QApplicationPrivate::notify_helper(QObject*, QEvent*)
    () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x00007ffff6f1a4c6 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x00000000004c1232 in Application::notify (this=<optimized out>, 
    receiver=0xdabf20, event=<optimized out>) at app/application.cpp:337
#13 0x00007ffff64c9b6b in QCoreApplication::notifyInternal(QObject*, QEvent*)
    () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x00007ffff651f0fd in QTimerInfoList::activateTimers() ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007ffff651f601 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007ffff4136fd7 in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff4137230 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff41372dc in g_main_context_iteration ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff65202df in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007ffff64c72fa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x00007ffff64cf3dc in QCoreApplication::exec() ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x00000000004c432b in Application::exec (this=this@entry=0xbf26c0, 
    params=...) at app/application.cpp:282
#23 0x00000000004bb2b3 in main (argc=1, argv=<optimized out>)
    at app/main.cpp:249
@sledgehammer999 commented on GitHub (Jan 20, 2016): @naikel I got a crash on Debian sid (libtorrent 1.0.7) with another random torrent: > magnet:?xt=urn:btih:a68d12b8b479a646bd7efae253f98610a5cd74cb&dn=%5bHorribleSubs%5d%20Kono%20Subarashii%20Sekai%20ni%20Shukufuku%20wo!%20-%2002%20%5b720p%5d.mkv&tr=http%3a%2f%2fopen.nyaatorrents.info%3a6544%2fannounce&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce I don't think it will help but here is gdb bt ``` Thread 1 (Thread 0x7ffff7e81900 (LWP 3578)): #0 libtorrent::combine_path ( lhs=<error reading variable: Cannot access memory at address 0xe4d5799e8>, rhs="") at ../../src/file.cpp:590 #1 0x00007ffff770a5c8 in libtorrent::file_storage::file_path (this=0x100d068, index=index@entry=1, save_path="") at ../../src/file_storage.cpp:581 #2 0x0000000000530934 in BitTorrent::TorrentInfo::filePath ( this=this@entry=0x7fffffffd400, index=1) at base/bittorrent/torrentinfo.cpp:150 #3 0x0000000000531525 in BitTorrent::TorrentInfo::filesForPiece ( this=this@entry=0x7fffffffd400, pieceIndex=pieceIndex@entry=1286) at base/bittorrent/torrentinfo.cpp:223 #4 0x00000000005d4bc3 in PeerListWidget::updatePeer ( this=this@entry=0xea35e0, ip=..., torrent=torrent@entry=0x1bf3ee0, peer=...) at gui/properties/peerlistwidget.cpp:372 #5 0x00000000005d660a in PeerListWidget::loadPeers (this=0xea35e0, torrent=0x1bf3ee0, forceHostnameResolution=forceHostnameResolution@entry=false) at gui/properties/peerlistwidget.cpp:286 #6 0x00000000005c705d in PropertiesWidget::loadDynamicData (this=0xe166f0) at gui/properties/propertieswidget.cpp:470 #7 0x00007ffff64f86ca in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x00007ffff6504f78 in QTimer::timerEvent(QTimerEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x00007ffff64f9543 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x00007ffff6f14ffc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #11 0x00007ffff6f1a4c6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #12 0x00000000004c1232 in Application::notify (this=<optimized out>, receiver=0xdabf20, event=<optimized out>) at app/application.cpp:337 #13 0x00007ffff64c9b6b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #14 0x00007ffff651f0fd in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #15 0x00007ffff651f601 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x00007ffff4136fd7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x00007ffff4137230 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #18 0x00007ffff41372dc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #19 0x00007ffff65202df in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #20 0x00007ffff64c72fa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #21 0x00007ffff64cf3dc in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #22 0x00000000004c432b in Application::exec (this=this@entry=0xbf26c0, params=...) at app/application.cpp:282 #23 0x00000000004bb2b3 in main (argc=1, argv=<optimized out>) at app/main.cpp:249 ```
Author
Owner

@naikel commented on GitHub (Jan 20, 2016):

Wow. This gets even weirder by the minute. In that crash in file_storage::file_path the string m_paths[fe.path_index] is invalid.

That can be for several reasons but I think it's because the internal_file_entry structure (from m_files[index]) is totally invalid, and that's from m_files[1], because index=1.

@naikel commented on GitHub (Jan 20, 2016): Wow. This gets even weirder by the minute. In that crash in file_storage::file_path the string m_paths[fe.path_index] is invalid. That can be for several reasons but I think it's because the internal_file_entry structure (from m_files[index]) is totally invalid, and that's from m_files[1], because index=1.
Author
Owner

@naikel commented on GitHub (Jan 20, 2016):

More info:

1.- That torrent has a single file and that should be m_files[0], why is it trying to access m_files[1]?

2.- Was that a libtorrent with --enable-debug? why the TORRENT_ASSERT_PRECOND didn't say anthing about index >= m_files.size()?

3.- Looks like map_block for an specific piece gives a file_slice with file_index >= num_files. In the particular case of this torrent, s.file_index has always to be zero. If it's one, it will crash.

@naikel commented on GitHub (Jan 20, 2016): More info: 1.- That torrent has a single file and that should be m_files[0], why is it trying to access m_files[1]? 2.- Was that a libtorrent with --enable-debug? why the TORRENT_ASSERT_PRECOND didn't say anthing about index >= m_files.size()? 3.- Looks like map_block for an specific piece gives a file_slice with file_index >= num_files. In the particular case of this torrent, s.file_index has always to be zero. If it's one, it will crash.
Author
Owner

@sledgehammer999 commented on GitHub (Jan 20, 2016):

2.- Was that a libtorrent with --enable-debug? why the TORRENT_ASSERT_PRECOND didn't say anthing about index >= m_files.size()?

No. I used the one from the debian repos. I only compiled qbt with debug.

Looks like map_block for an specific piece gives a file_slice with file_index >= num_files. In the particular case of this torrent, s.file_index has always to be zero. If it's one, it will crash.

Maybe an off-by-one bug in libtorrent?
(I wonder why my previous prints didn't detect the out of bounds index).

@sledgehammer999 commented on GitHub (Jan 20, 2016): > 2.- Was that a libtorrent with --enable-debug? why the TORRENT_ASSERT_PRECOND didn't say anthing about index >= m_files.size()? No. I used the one from the debian repos. I only compiled qbt with debug. > Looks like map_block for an specific piece gives a file_slice with file_index >= num_files. In the particular case of this torrent, s.file_index has always to be zero. If it's one, it will crash. Maybe an off-by-one bug in libtorrent? (I wonder why my previous prints didn't detect the out of bounds index).
Author
Owner

@naikel commented on GitHub (Jan 20, 2016):

The thing is, if that's the problem, a check before calling filePath that file_index < num_files is enough, even if map_block in libtorrent has a bug.

@naikel commented on GitHub (Jan 20, 2016): The thing is, if that's the problem, a check before calling filePath that file_index < num_files is enough, even if map_block in libtorrent has a bug.
Author
Owner

@arvidn commented on GitHub (Jan 20, 2016):

If you're debugging optimized builds, I would take what the debugger is saying with a grain of salt. and I would recommend testing debug builds of libtorrent as well libstdc++, by defining _GLIBCXX_DEBUG or _GLIBCXX_ASSERT (the latter preserves ABI).

It looks like the internal_file_entry is invalid for some reason. It could be an index out-of-range or the underlying vector may have been reallocated or the underlying object that holds the file_storage object may have been destroyed.

I could add more debug tracking and asserts around this function, but unless you build in debug mode, it won't do much good

@arvidn commented on GitHub (Jan 20, 2016): If you're debugging optimized builds, I would take what the debugger is saying with a grain of salt. and I would recommend testing debug builds of libtorrent as well libstdc++, by defining _GLIBCXX_DEBUG or _GLIBCXX_ASSERT (the latter preserves ABI). It looks like the internal_file_entry is invalid for some reason. It could be an index out-of-range or the underlying vector may have been reallocated or the underlying object that holds the file_storage object may have been destroyed. I could add more debug tracking and asserts around this function, but unless you build in debug mode, it won't do much good
Author
Owner

@glassez commented on GitHub (Jan 21, 2016):

Damn, I just downloaded affected torrent from beginning to end without crash!
I don't like this bug...

@glassez commented on GitHub (Jan 21, 2016): Damn, I just downloaded affected torrent from beginning to end without crash! I don't like this bug...
Author
Owner

@Nemo-qB commented on GitHub (Jan 21, 2016):

And qBittorrent is stable again with v3.3.3 :). Thanks for the new build.

@Nemo-qB commented on GitHub (Jan 21, 2016): And qBittorrent is stable again with v3.3.3 :). Thanks for the new build.
Author
Owner

@zywo commented on GitHub (Jan 21, 2016):

I reported the issue 17 days ago: https://github.com/qbittorrent/qBittorrent/issues/4501

Ubuntu 15.10
v3.4.0alpha
qt 4.8.6
libtorrent 1.0.6.0
boost 1.58.0

@zywo commented on GitHub (Jan 21, 2016): I reported the issue 17 days ago: https://github.com/qbittorrent/qBittorrent/issues/4501 Ubuntu 15.10 v3.4.0alpha qt 4.8.6 libtorrent 1.0.6.0 boost 1.58.0
Author
Owner

@glassez commented on GitHub (Jan 21, 2016):

@zywo how many files in affected torrent? (when program crashed as you reported in #4501)

@glassez commented on GitHub (Jan 21, 2016): @zywo how many files in affected torrent? (when program crashed as you reported in #4501)
Author
Owner

@glassez commented on GitHub (Jan 21, 2016):

@zywo can you provide this torrent for testing? (unless it's some private torrent of course)

@glassez commented on GitHub (Jan 21, 2016): @zywo can you provide this torrent for testing? (unless it's some private torrent of course)
Author
Owner

@zywo commented on GitHub (Jan 21, 2016):

@glassez I don't remember how many files.

I just reproduced the crash with this torrent: af420a4945e5d8fec790202541903eae2e924a0f

@zywo commented on GitHub (Jan 21, 2016): @glassez I don't remember how many files. I just reproduced the crash with this torrent: af420a4945e5d8fec790202541903eae2e924a0f
Author
Owner

@glassez commented on GitHub (Jan 21, 2016):

I just reproduced the crash with this torrent: af420a4945e5d8fec790202541903eae2e924a0f

@zywo, Please describe more the circumstances of this event. What tabs were opened. The main window has been shown or minimized, etc. How much (approx.) time has passed since the launch of torrent.

@glassez commented on GitHub (Jan 21, 2016): > I just reproduced the crash with this torrent: af420a4945e5d8fec790202541903eae2e924a0f @zywo, Please describe more the circumstances of this event. What tabs were opened. The main window has been shown or minimized, etc. How much (approx.) time has passed since the launch of torrent.
Author
Owner

@zywo commented on GitHub (Jan 21, 2016):

  • The main window is maximized;
  • "Transfers" and "Peers" tabs are open;
  • Approximately, from 5 to 20 minutes.
@zywo commented on GitHub (Jan 21, 2016): - The main window is maximized; - "Transfers" and "Peers" tabs are open; - Approximately, from 5 to 20 minutes.
Author
Owner

@hdcTenBasePid commented on GitHub (Jan 21, 2016):

Just to muddy the waters,

  • didn't mater if I was VPNing or direct,
    • Options - Download - Incomplete to x:\Temp, Save to x:\Done
    • Options - BitTorrent - Require Encryption
    • Options - Advanced - No GeoIP, No Resolve peer names, if VPN then selected in Network Interface
    • Most other settings default
  • All torrents are Magnets
  • Never maximized qBT
  • The left pane had
    • Sources (Resumed)
    • Labels (All)
    • Trackers (De-selected)
  • Transfer pane - 1 selected torrent - I was checking as there were 1500 plus Seeds and could only attach to 2 of them so ..
  • Info pane - Trackers was looked at, then Peers was open to see 50 (my limit) seeds with 48 chocked, me Interested
  • Leech/Seeding crash 4 odd hours into session, the Seeding crash about 10 hours, until I checked the peers on one.
  • As mentioned the up/downloading continued behind the Crash notice, without corruption or wastage (odd!).

Previous to this ,but in the same session I experienced #4611, which I let run for about an hour, then cancelled, and started again, magnets. (Second time good.)

Now to move on for the moment will check out 3.3.3. Happy hunting ...

@hdcTenBasePid commented on GitHub (Jan 21, 2016): Just to muddy the waters, - didn't mater if I was VPNing or direct, - Options - Download - Incomplete to x:\Temp, Save to x:\Done - Options - BitTorrent - Require Encryption - Options - Advanced - No GeoIP, No Resolve peer names, if VPN then selected in Network Interface - Most other settings default - All torrents are Magnets - Never maximized qBT - The left pane had - Sources (Resumed) - Labels (All) - Trackers (De-selected) - Transfer pane - 1 selected torrent - I was checking as there were 1500 plus Seeds and could only attach to 2 of them so .. - Info pane - Trackers was looked at, then Peers was open to see 50 (my limit) seeds with 48 chocked, me Interested - Leech/Seeding crash 4 odd hours into session, the Seeding crash about 10 hours, until I checked the peers on one. - As mentioned the up/downloading continued behind the Crash notice, without corruption or wastage (odd!). Previous to this ,but in the same session I experienced #4611, which I let run for about an hour, then cancelled, and started again, magnets. (Second time good.) Now to move on for the moment will check out 3.3.3. Happy hunting ...
Author
Owner

@glassez commented on GitHub (Jan 21, 2016):

Catched!
I downloaded this torrent a few times and got the crash in all cases except one. I slightly modified the code to suppress the crash and print some information into the log:

for (const libtorrent::file_slice& s: files) {
        if (s.file_index >= filesCount()) {
            Logger::instance()->addMessage(QString("File index (%1) for piece %2 of %3 out of bound!").arg(s.file_index).arg(pieceIndex + 1).arg(piecesCount()), Log::CRITICAL);
        }
        else {
            res.append(filePath(s.file_index));
        }
    }

And here's what I got every time this has happened (torrent has 1 file):

File index (1) for piece 2202 of 2202 out of bound!

It turns out that this is a bug in the library, with the result that `torrent_info::map_block()`` returns extra file for the last part (for some reason, not constantly).
@arvidn?

@glassez commented on GitHub (Jan 21, 2016): Catched! I downloaded this torrent a few times and got the crash in all cases except one. I slightly modified the code to suppress the crash and print some information into the log: ``` c++ for (const libtorrent::file_slice& s: files) { if (s.file_index >= filesCount()) { Logger::instance()->addMessage(QString("File index (%1) for piece %2 of %3 out of bound!").arg(s.file_index).arg(pieceIndex + 1).arg(piecesCount()), Log::CRITICAL); } else { res.append(filePath(s.file_index)); } } ``` And here's what I got every time this has happened (torrent has 1 file): > File index (1) for piece 2202 of 2202 out of bound! It turns out that this is a bug in the library, with the result that `torrent_info::map_block()`` returns extra file for the last part (for some reason, not constantly). @arvidn?
Author
Owner

@arvidn commented on GitHub (Jan 21, 2016):

there's a subtle issue when using map_file() (and I imagine the same is true for map_block()) for the last byte of the torrent (or more likely, the one-past-the-end byte). in the dump_torrent.cpp example there's some careful arithmetic to make sure that the returned ranges is within the torrent. specifically, take a look at this line:

https://github.com/arvidn/libtorrent/blob/master/examples/dump_torrent.cpp#L197

to map a file to a first-piece and a last-piece, map_file() is invoked twice, once for the first byte of the file, and once for the last byte of the file.

What's the context you use map_block() in? could you provide a link to the source?

@arvidn commented on GitHub (Jan 21, 2016): there's a subtle issue when using map_file() (and I imagine the same is true for map_block()) for the last byte of the torrent (or more likely, the one-past-the-end byte). in the dump_torrent.cpp example there's some careful arithmetic to make sure that the returned ranges is within the torrent. specifically, take a look at this line: https://github.com/arvidn/libtorrent/blob/master/examples/dump_torrent.cpp#L197 to map a file to a first-piece and a last-piece, map_file() is invoked twice, once for the first byte of the file, and once for the last byte of the file. What's the context you use map_block() in? could you provide a link to the source?
Author
Owner

@zeule commented on GitHub (Jan 21, 2016):

We call it with arguments (pieceIndex, 0, torrent_info::piece_length()). PieceIndex we obtain from peer_info::downloading_piece_index.
Since the code was reverted here is the original pull request
The code is in src/base/bittorrent/torrentinfo.cpp

@zeule commented on GitHub (Jan 21, 2016): We call it with arguments (pieceIndex, 0, torrent_info::piece_length()). PieceIndex we obtain from peer_info::downloading_piece_index. Since the code was reverted here is the original [pull request](https://github.com/qbittorrent/qBittorrent/pull/2885/files) The code is in src/base/bittorrent/torrentinfo.cpp
Author
Owner

@arvidn commented on GitHub (Jan 21, 2016):

I think the problem is that you pass in the generic piece_length() as the size of the block. If the last piece is shorter than that, you'll be mapping space past the end of the torrent. In debug builds this should yield an assert. If you instead pass in nativeInfo()->piece_size(pieceIndex) I imagine it would work

@arvidn commented on GitHub (Jan 21, 2016): I think the problem is that you pass in the generic piece_length() as the size of the block. If the last piece is shorter than that, you'll be mapping space past the end of the torrent. In debug builds this should yield an assert. If you instead pass in nativeInfo()->piece_size(pieceIndex) I imagine it would work
Author
Owner

@arvidn commented on GitHub (Jan 21, 2016):

given that this is such an easy mistake to make, I should probably add a run-time check and just truncate the response

@arvidn commented on GitHub (Jan 21, 2016): given that this is such an easy mistake to make, I should probably add a run-time check and just truncate the response
Author
Owner

@naikel commented on GitHub (Jan 21, 2016):

If you instead pass in nativeInfo()->piece_size(pieceIndex)

Does this mean different pieces can have different sizes? I didn't know Bittorrent protocol allowed that...

@naikel commented on GitHub (Jan 21, 2016): > If you instead pass in nativeInfo()->piece_size(pieceIndex) Does this mean different pieces can have different sizes? I didn't know Bittorrent protocol allowed that...
Author
Owner

@arvidn commented on GitHub (Jan 21, 2016):

every piece except for the last one have the same size.. but it's not required the size of the torrent be divisible by that piece size, so the last piece is most likely shorter

@arvidn commented on GitHub (Jan 21, 2016): every piece except for the last one have the same size.. but it's not required the size of the torrent be divisible by that piece size, so the last piece is most likely shorter
Author
Owner

@zeule commented on GitHub (Jan 21, 2016):

All this looks very clear now. Thanks a lot! And indeed, either a note in the documentation or truncation of the values which are out of range would be nice to have.

@zeule commented on GitHub (Jan 21, 2016): All this looks very clear now. Thanks a lot! And indeed, either a note in the documentation or truncation of the values which are out of range would be nice to have.
Author
Owner

@arvidn commented on GitHub (Jan 21, 2016):

I would highly recommend using a debug build of libtorrent during development. if all the invariant checks in there are too slow, they can be disabled. I would expect an assert to fire consistently on any seeding torrent that invokes this (in debug mode)

@arvidn commented on GitHub (Jan 21, 2016): I would highly recommend using a debug build of libtorrent during development. if all the invariant checks in there are too slow, they can be disabled. I would expect an assert to fire consistently on any seeding torrent that invokes this (in debug mode)
Author
Owner

@sledgehammer999 commented on GitHub (Mar 17, 2016):

Fixed with #4867

@sledgehammer999 commented on GitHub (Mar 17, 2016): Fixed with #4867
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/qBittorrent#3751
No description provided.