Crash on 1.2.0.0

[mikegriff]

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Windows\system32>C:\MinGW\bin\gdb.exe
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
there is more in the txt file
the last line of below is
target exec C:\ultracopier-debug-real-windows-x86-1.2.0.4\ultracopier-debug-real-windows-x86\ultracopier.exe



License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
<\ultracopier-debug-real-windows-x86\ultracopier.exe
The program is not being run.
(gdb) run
Starting program:
No executable specified, use `target exec'.
(gdb) target exec
No executable file now.
<-x86-1.2.0.4\ultracopier-debug-real-windows-x86\ultracopier.exe

[alpha_one_x86]

Enter:

Code: Select all

cd C:\MinGW\bin\
C:\MinGW\bin\gdb.exe C:\ultracopier-debug-real-windows-x86-1.2.0.4\ultracopier-debug-real-windows-x86\ultracopier.exe
run
... do the crash
bt

[mikegriff]

Sorry
I just get this info screen

I have run drmingw.exe -i
it then confirmed it was installed but however i run it it pops up the info screen

[alpha_one_x86]

With with gdb? Forget drmingw...

[alpha_one_x86]

http://ultracopier.first-world.info/tem ... 1.2.1.0.7z
Start the bat
enter:

Code: Select all

b abort
b exit
run

Do the crash
enter:

Code: Select all

bt

repport me the text

[brain99]

I installed Ultracopier earlier today, and the first few times it worked well - copying more than 100k files was noticeably faster than using the built-in file copy of Windows.

Using some trial and error, I found that increasing inode threads greatly increased performance for my workload (I found a suggestion online to use 16 threads). However, I have noticed some issues when using that setting.

• I got an error about not being able to copy file times; being new to the program I was going to change the settings and re-do the copy later (I did not realize at the time I could probably change the settings for that operation only and reprocess only the failed files). This itself may not be a bug/issue, but is important for what follows.
• It seems some files in the list are not being processed. Maybe due to thread or parallelism settings? At any rate, with the few copy operations I did about 1-10 files remained in the list after which copying effectively stopped.
• When trying to re-do the copy to get all missing files due to the above 2 points, Ultracopier now crashes whereas before it was perfectly happy to start copying those folders.
• It seems Ultracopier needs a long time initializing the UI after dragging files in Windows Explorer: about 8 seconds before any UI appears at all, a further 13 seconds before it asks me what to do with a folder conflict (I chose always merge), and after that it's about 15 seconds before it crashes. The non-debug version seems slightly faster, but not by much (it still takes more than 35 seconds before it crashes or starts copying). I don't remember if it was that slow before Ultracopier started crashing; but if it was, I thought nothing of it since it may not be abnormal for a list of 100k files. For only a few small files however, this seems unacceptably slow.

If I set inode threads to 1, everything works again. So it definitely seems like this has something to do with the number of files to actually copy (after merging the file list) in relation to the number of threads. The issue of some files in the list not being processed at all also seems not to occur with only 1 inode thread, and it also needs much less time to actually start copying files (about 6 seconds to show the UI, 3-4 more seconds before I get the overwrite/skip/merge dialog, and then it immediately starts processing files). While still slower than native Windows UI, 10 seconds is much more acceptable than 30-40 seconds.

Anyway, since I have experienced crashes I thought I would provide you with the requested debugging information. Depending on which (sub)folder I try to copy, I have seen 2 different stack traces, which I attached to this post. There may be more if I try other folders, but this should at least give you something to start with.

If you have any further questions, just let me know!

[alpha_one_x86]

Using some trial and error, I found that increasing inode threads greatly increased performance for my workload (I found a suggestion online to use 16 threads). However, I have noticed some issues when using that setting.

This option at 1 is safe (it's why it's defaut), at 16 is buggy.

It seems Ultracopier needs a long time initializing the UI after dragging files in Windows Explorer: about 8 seconds before any UI appears at all, a further 13 seconds before it asks me what to do with a folder conflict (I chose always merge), and after that it's about 15 seconds before it crashes. The non-debug version seems slightly faster, but not by much (it still takes more than 35 seconds before it crashes or starts copying). I don't remember if it was that slow before Ultracopier started crashing; but if it was, I thought nothing of it since it may not be abnormal for a list of 100k files. For only a few small files however, this seems unacceptably slow.

I don't have problem with millions of file here...

If I set inode threads to 1, everything works again. So it definitely seems like this has something to do with the number of files to actually copy (after merging the file list) in relation to the number of threads. The issue of some files in the list not being processed at all also seems not to occur with only 1 inode thread, and it also needs much less time to actually start copying files (about 6 seconds to show the UI, 3-4 more seconds before I get the overwrite/skip/merge dialog, and then it immediately starts processing files). While still slower than native Windows UI, 10 seconds is much more acceptable than 30-40 seconds.

Profiling on your computer seam be the unique solution, but will be very complicated for you.

Anyway, since I have experienced crashes I thought I would provide you with the requested debugging information. Depending on which (sub)folder I try to copy, I have seen 2 different stack traces, which I attached to this post. There may be more if I try other folders, but this should at least give you something to start with.

The next week I will work on this, remind me if I forgot.

[brain99]

This option at 1 is safe (it's why it's defaut), at 16 is buggy.

I will keep it at 1 then, and only temporarily increase for specific workloads. For copying my 100k files, there was a noticeable difference in performance...

Profiling on your computer seam be the unique solution, but will be very complicated for you.

Define "very complicated" I do a bit of software development myself so I'm used to having all kinds of development-related tools (even if I don't normally use C++).
That being said, I see no obvious bottleneck while Ultracopier is initializing (no significant CPU usage, no disk activity to speak of, temporarily disabling antivirus etc didn't change anything) so finding the root cause may indeed be non-trivial.

If it makes any difference, I'm on a Win 8.1 x64 system.

[alpha_one_x86]

I will keep it at 1 then, and only temporarily increase for specific workloads. For copying my 100k files, there was a noticeable difference in performance...

Nobody have debug this options, and I don't have found how do it... but I continue.

Define "very complicated"

Search profiling tool on your platform (I use valgrind under linux), compatible with mingw.

That being said, I see no obvious bottleneck while Ultracopier is initializing (no significant CPU usage, no disk activity to speak of, temporarily disabling antivirus etc didn't change anything) so finding the root cause may indeed be non-trivial.

http://ultracopier-wiki.first-world.inf ... umentation
The version 2 will have great performance improvement because it will bevent on event + async and not thread. But I have not fund and time to do that's.