Opened 17 years ago

Last modified 5 years ago

#83 closed Bug report

Crash on file transfer

Reported by: azzytee Owned by: Tim Kosse
Priority: critical Component: Other
Keywords: Cc: azzytee, Tim Kosse
Component version: Operating system type:
Operating system version:

Description

Seemingly randomly, but reoccouring. FileZilla
crashes on a large file transfer.

Crashes with the following information:

Socket Notification Sink: FileZilla.exe - Application
Error

The instruction at "0x73dd3eb8" referenced memory
at "0x00000000". The memory could not be "read".

Click on OK to terminate the program
Click on CANCEL to debug the program

When clicked debug, I receive

Microsoft Visual C++

Unhandled exception in FileZilla.exe (MFC42.DLL);
0xC0000005: Access Violation.

And the following line is marked
73DDD3EB8 mov eax,dword ptr [edi]

As for system information, I'm running a Pentium 4
1.4ghz with 768 megs of ram, plenty of disk space (no
low disk space problems), WindowsXP, LAN connected to
DSL via a Microsoft SOCKS4 proxy.

Thanks for the great ftp client, keep up the good
work.

Attachments (2)

debugscreen.jpg (198.1 KB) - added by azzytee 17 years ago.
Screenshot of MSVC++ in debug.
vc.gif (59.4 KB) - added by azzytee 17 years ago.
VC++ call stack crash stuff

Download all attachments as: .zip

Change History (7)

Changed 17 years ago by azzytee

Attachment: debugscreen.jpg added

Screenshot of MSVC++ in debug.

comment:1 Changed 17 years ago by Tim Kosse

Could you please try to compile a debug version of
FileZilla and run it inside the debugger?
If it crashes again, please send me the contents of the
call stack (press ALT+7 to show it).
Then I should be able to locate the error.

comment:2 Changed 17 years ago by azzytee

OK, I will try to do this tomorrow. Although I know very
little about VC++ (or C++ for that matter), Just have
Visual Studio installed for VB.

The crash happened very frequently, and didn't seem to
only be on large files, so I'm sure I can reproduce it. I
ended up going back to 1.7b and haven't had any problems
(if I recall correctly), but with both of the 1.8x
releases I had this crash.

comment:3 Changed 17 years ago by Tim Kosse

You could also try the following:
In the settiings dialog go to the debug page and
enable "Trace messages from the ftp engine" and "Log to
File" (enter a valid filename) Then connect to a server and
transfer some files. When FileZilla crashes, please post
the log file.
Using the log you can see which functions have been called
beforce the crash.

Changed 17 years ago by azzytee

Attachment: vc.gif added

VC++ call stack crash stuff

comment:4 Changed 17 years ago by azzytee

Damn! It took 3 hours before crashing today, yesterday it
was only a half hour or so. But it finally crashed when
in debug mode. I don't understand the output, but I hope
it helps.

<BEGIN CALL STACK>

CString::GetData() line 122 + 13 bytes
CString::CString(const CString & {???}) line 53 + 8 bytes
t_server::t_server(const t_server & {...}) + 62 bytes
CDirectoryCache::Purge(const CServerPath & {...}, const
t_server * 0x00000000) line 248 + 27 bytes
CDirectoryCache::Lookup(const CServerPath & {...},
t_server {...}, t_directory & {...}) line 67
CControlSocket::FileTransfer(t_transferfile * 0x00000000,
int 0, int 0) line 1743 + 60 bytes
CControlSocket::ProcessReply() line 380
CMainThread::PreTranslateMessage(tagMSG * 0x00544cc8
{msg=0x0000c238 wp=0x00000000 lp=0x00000000}) line 185
CWinThread::PumpMessage() line 841 + 30 bytes
CWinThread::Run() line 480 + 11 bytes
_AfxThreadEntry(void * 0x0012f230) line 125 + 11 bytes
_threadstartex(void * 0x005439f0) line 212 + 13 bytes
KERNEL32! 77e802ed()

<END CALL STACK>

I've attached a screenshot of the call stack window and
the VC++ window. I will try the Trace messages option and
next time it crashes post that, if neccessary.

Thank you!

comment:5 Changed 17 years ago by Tim Kosse

I've found the bug. After reaching the maximum time a
directory is stored in the dircache, it will be removed the
cache (CDirectoryCache::Purge)
This function was called with the wrong parameters given
and could also crash when a root directory gets purged.
The fixed version will be released in one or two days,
until then I suggest you to increase the maximum cache time
to 999 hours.

Note: See TracTickets for help on using tickets.