Hello Zenju
The version no longer encounters the old Gamma / RGB problem but this version crashes randomly...
I send the last three dumps that FreeFileSync has pulled : "FreeFileSync_Win32.exe 14.3 CrashDump 2025-03-04"
URL for dump : https://transfert.free.fr/J3wNoAz Validity 30 days
As this version is beta, I send you the dumps as attachments to this message.
Please let me know if you open a post in the forum. You can also reply to my email address
To be continued
Thanks for the rest
FreeFileSync_Win32.exe 14.3 CrashDump
- Posts: 21
- Joined: 17 Dec 2022
- Posts: 21
- Joined: 17 Dec 2022
Hi
For information, after restoring version 14.0 - 32 Bits 01/17/2025 Donation Edition, I have no problem with backup or synchronization. All definitions work perfectly under this version. The problems occurred from version 14.2
Good day
For information, after restoring version 14.0 - 32 Bits 01/17/2025 Donation Edition, I have no problem with backup or synchronization. All definitions work perfectly under this version. The problems occurred from version 14.2
Good day
-
- Site Admin
- Posts: 7348
- Joined: 9 Dec 2007
Can you replace "FreeFileSync_Win32.exe" from your installation subdirectory "Bin" with the following version and try again if you can reproduce the crash where you load D:\$FreeFileSync_Data\Save_X_Documents_sur_D.ffs_batch?
https://www.mediafire.com/file/jd90s5wrp4sa6p5/FreeFileSync_Win32.exe
https://www.mediafire.com/file/jd90s5wrp4sa6p5/FreeFileSync_Win32.exe
- Posts: 21
- Joined: 17 Dec 2022
Hi Zenju
FFS is currently working without any problems with the version downloaded via https://www.mediafire.com/file/0ih2isrifm18ibf/FreeFileSync_14.3_%255BBeta%255D_Windows_Setup.exe
I deleted and redefined the batch D:\$FreeFileSync_Data\Save_X_Documents_sur_D.ffs_batch which was causing problems and now there is no more crash. 👍
The startup script which manages all my synchronizations and backups is working normally again with FreeFileSync and RealTimeSync.👌
We can close the post
Thanks for your follow-up
See you in the next version 😉
FFS is currently working without any problems with the version downloaded via https://www.mediafire.com/file/0ih2isrifm18ibf/FreeFileSync_14.3_%255BBeta%255D_Windows_Setup.exe
I deleted and redefined the batch D:\$FreeFileSync_Data\Save_X_Documents_sur_D.ffs_batch which was causing problems and now there is no more crash. 👍
The startup script which manages all my synchronizations and backups is working normally again with FreeFileSync and RealTimeSync.👌
We can close the post
Thanks for your follow-up
See you in the next version 😉
-
- Site Admin
- Posts: 7348
- Joined: 9 Dec 2007
This is bad. I only changed the code inside the "impossible" path in order to add debug info. So this is a heisenbug, apparently bad codegen in 32-bit with the latest VC C++ compiler version 19.43.34808.
I have a hunch that this is related: https://developercommunity.visualstudio.com/t/Use-of-the-result-of-bsr-before-that-i/10862351?q=_BitScanReverse64
I have a hunch that this is related: https://developercommunity.visualstudio.com/t/Use-of-the-result-of-bsr-before-that-i/10862351?q=_BitScanReverse64
- Posts: 21
- Joined: 17 Dec 2022
Hello Zenju
I'm getting back to you because the Beta 14.3 version is not stable. It has crash contexts that I can't explain, whether in batch or from the FFS application. This goes as far as not being able to launch FFS because the app no longer opens and dumps each time it tries; the only solution is to reboot the PC, but the improvement is only temporary...
I just spent a lot of time to redo the backup (mirror) and synchronization (two-way) definitions "cleanly". Nothing works...
I noticed that the execution times are particularly long because FFS does not always use the "sync.ffs_db" databases and as a result, all directories and files are reread.
To get out of it, I just reinstalled version 14.0 and everything is going very well. No crash, systematic use of sync.ffs_db and therefore in the end, a "normal" execution time for the script.
I will stay in this version while waiting for the next one which will perhaps resolve all these malfunctions.
Good luck and best regards
Gérard
PS.: the problems only concern the Windows x32 version. The x64 version 14.2 works perfectly.
I'm getting back to you because the Beta 14.3 version is not stable. It has crash contexts that I can't explain, whether in batch or from the FFS application. This goes as far as not being able to launch FFS because the app no longer opens and dumps each time it tries; the only solution is to reboot the PC, but the improvement is only temporary...
I just spent a lot of time to redo the backup (mirror) and synchronization (two-way) definitions "cleanly". Nothing works...
I noticed that the execution times are particularly long because FFS does not always use the "sync.ffs_db" databases and as a result, all directories and files are reread.
To get out of it, I just reinstalled version 14.0 and everything is going very well. No crash, systematic use of sync.ffs_db and therefore in the end, a "normal" execution time for the script.
I will stay in this version while waiting for the next one which will perhaps resolve all these malfunctions.
Good luck and best regards
Gérard
PS.: the problems only concern the Windows x32 version. The x64 version 14.2 works perfectly.
-
- Site Admin
- Posts: 7348
- Joined: 9 Dec 2007
Visual Studio 17.13.3 just released. Maybe the 32-bit codegen bug has been fixed?
https://www.mediafire.com/file/mgzl3vvwayzcgd5/FreeFileSync_14.3_%255BBeta%255D_Windows_Setup%25282%2529.exe
https://www.mediafire.com/file/mgzl3vvwayzcgd5/FreeFileSync_14.3_%255BBeta%255D_Windows_Setup%25282%2529.exe
- Posts: 21
- Joined: 17 Dec 2022
OK, I'll keep you informed.
Have a nice day.
Have a nice day.
- Posts: 21
- Joined: 17 Dec 2022
Hello Zenju
The new module works better than the previous one, but there are still problems because it generates dumps...
I have the impression that there's a problem between FreeFileSync and RealTimeSync. Launching FFS generates a dump because RTS is active. Once RTS is stopped, FFS finally opens without creating a dump, and I can finally access the Configuration screen.
I'm attaching two zip files containing the dumps that correspond to what I wrote above.
To be continued 😉
https://transfert.free.fr/QUIbTDm validity 30 days
https://transfert.free.fr/9QFqU2L validity 30 days
The new module works better than the previous one, but there are still problems because it generates dumps...
I have the impression that there's a problem between FreeFileSync and RealTimeSync. Launching FFS generates a dump because RTS is active. Once RTS is stopped, FFS finally opens without creating a dump, and I can finally access the Configuration screen.
I'm attaching two zip files containing the dumps that correspond to what I wrote above.
To be continued 😉
https://transfert.free.fr/QUIbTDm validity 30 days
https://transfert.free.fr/9QFqU2L validity 30 days
- Posts: 21
- Joined: 17 Dec 2022
Hi
This morning, I confirmed the impression I had yesterday. While all the Save and Synchro script processes ran smoothly and the RTS tasks were active, opening FFS via the desktop icon crashes and causes a dump. I'm attaching it.
Thanks.
https://transfert.free.fr/1ckVNtf
This morning, I confirmed the impression I had yesterday. While all the Save and Synchro script processes ran smoothly and the RTS tasks were active, opening FFS via the desktop icon crashes and causes a dump. I'm attaching it.
Thanks.
https://transfert.free.fr/1ckVNtf
-
- Site Admin
- Posts: 7348
- Joined: 9 Dec 2007
It's always the same crash:
std::length error is thrown (_Xlength_error("invalid hash bucket count")) as a consequence of
The Bucket size of std::_Hash is apparently 1, and the container size is 8 before the insert of 1 additional item. So _Req_buckets should be 9, which according to _Desired_grow_bucket_count() should yield 8 * 8 = 64 _Buckets! But it's 2.147.483.648 for whatever reason.
@vika51: The crash seems to be consistently happening when loading your config file:
I'm not able to reproduce this crash on my machine, however, but suspect it may be hardware-related. I believe something goes wrong with floating point calculations (which are weirdly used instead of integer math for bucket size calculation).
What are the CPU specs of the machine where the crash occurs?
KERNELBASE.dll!_RaiseException@16() Unknown
FreeFileSync_Win32.exe!_CxxThrowException(void * pExceptionObject=0x01f3e190, const _s__ThrowInfo * pThrowInfo=0x01a426c8) Line 79 C++
FreeFileSync_Win32.exe!std::_Xlength_error(const char * _Message) Line 19 C++
FreeFileSync_Win32.exe!std::_Hash<std::_Umap_traits<std::string,wxImage,std::_Uhash_compare<std::string,std::hash<std::string>,std::equal_to<std::string>>,std::allocator<std::pair<std::string const ,wxImage>>,0>>::_Forced_rehash(unsigned int _Buckets) Line 1690 C++
> [Inline Frame] FreeFileSync_Win32.exe!std::_Hash<std::_Umap_traits<std::string,std::_List_iterator<std::_List_val<std::_List_simple_types<zen::XmlElement>>>,std::_Uhash_compare<std::string,std::hash<std::string>,std::equal_to<std::string>>,std::allocator<std::pair<std::string const ,std::_List_iterator<std::_List_val<std::_List_simple_types<zen::XmlElement>>>>>,0>>::_Rehash_for_1() Line 1633 C++
FreeFileSync_Win32.exe!std::_Hash<std::_Umap_traits<std::string,std::_List_iterator<std::_List_val<std::_List_simple_types<zen::XmlElement>>>,std::_Uhash_compare<std::string,std::hash<std::string>,std::equal_to<std::string>>,std::allocator<std::pair<std::string const ,std::_List_iterator<std::_List_val<std::_List_simple_types<zen::XmlElement>>>>>,0>>::emplace<std::string,std::_List_iterator<std::_List_val<std::_List_simple_types<zen::XmlElement>>> &>(std::string && <_Vals_0>, std::_List_iterator<std::_List_val<std::_List_simple_types<zen::XmlElement>>> & <_Vals_1>) Line 618 C++
[Inline Frame] FreeFileSync_Win32.exe!zen::XmlElement::addChild(std::string) Line 111 C++
_Buckets (0x80 00 00 00 = 2.147.483.648) > _Max_storage_buckets (0x10 00 00 00 = 268.435.456
@vika51: The crash seems to be consistently happening when loading your config file:
I'm not able to reproduce this crash on my machine, however, but suspect it may be hardware-related. I believe something goes wrong with floating point calculations (which are weirdly used instead of integer math for bucket size calculation).
What are the CPU specs of the machine where the crash occurs?
- Posts: 21
- Joined: 17 Dec 2022
Hi Zenju
Following your last message, which seemed to imply a hardware problem, I completely checked the PC.
For the CPU specs : https://transfert.free.fr/pAPSkA3
For the system part, I ran the commands below and no problems were found or corrected:
sfc /scannow
dism.exe /Online /Cleanup-Image /AnalyzeComponentStore
dism.exe /Online /Cleanup-Image /Restorehealth
dism.exe /Online /Cleanup-Image /StartComponentCleanup
dism.exe /Online /Get-Packages
sfc /scannow
For the SSD drives, C:\, D:\, and F:\, I ran chkdsk /f /r on them. No errors were found or corrected. This took a very long time (2 days) because the drives are very large (1 and 2 TB).
For FFS and RTS, I redefined all the configurations: ffs_gui, ffs_batch, and ffs_real.
Finally, I restarted the PC, and the initial script ran fine (6 batch and 3 real). I then tried to open FFS via the desktop icon, and it crashed with a dump. I tried again several times (3-4), each time creating a dump, but the last attempt ended up opening FFS. When opening a configuration, FFS crashes and creates a dump…
So I shut down and restarted the PC. And then the script crashed while creating a dump…
So, I reinstalled 14.0. It works perfectly! All the contexts that crashed 14.2 and 14.3 Beta run normally and without any problems with 14.0. I think this 14.0 is the right stable base for further development.
To be continued therefore...
Best regards
Following your last message, which seemed to imply a hardware problem, I completely checked the PC.
For the CPU specs : https://transfert.free.fr/pAPSkA3
For the system part, I ran the commands below and no problems were found or corrected:
sfc /scannow
dism.exe /Online /Cleanup-Image /AnalyzeComponentStore
dism.exe /Online /Cleanup-Image /Restorehealth
dism.exe /Online /Cleanup-Image /StartComponentCleanup
dism.exe /Online /Get-Packages
sfc /scannow
For the SSD drives, C:\, D:\, and F:\, I ran chkdsk /f /r on them. No errors were found or corrected. This took a very long time (2 days) because the drives are very large (1 and 2 TB).
For FFS and RTS, I redefined all the configurations: ffs_gui, ffs_batch, and ffs_real.
Finally, I restarted the PC, and the initial script ran fine (6 batch and 3 real). I then tried to open FFS via the desktop icon, and it crashed with a dump. I tried again several times (3-4), each time creating a dump, but the last attempt ended up opening FFS. When opening a configuration, FFS crashes and creates a dump…
So I shut down and restarted the PC. And then the script crashed while creating a dump…
So, I reinstalled 14.0. It works perfectly! All the contexts that crashed 14.2 and 14.3 Beta run normally and without any problems with 14.0. I think this 14.0 is the right stable base for further development.
To be continued therefore...
Best regards
-
- Site Admin
- Posts: 7348
- Joined: 9 Dec 2007
I've created a ticket on the Visual Studio support forum: https://developercommunity.visualstudio.com/t/Bad-x86-codegen-for-hash-map-in-VS-1713/10872085
- Posts: 21
- Joined: 17 Dec 2022
Perfect ! There's nothing left to do but wait 👍
- Posts: 21
- Joined: 17 Dec 2022
Hi Zenju
Has VisualStudio fixed this issue? If so, is this 14.3 version OK on Win32?
Has VisualStudio fixed this issue? If so, is this 14.3 version OK on Win32?
-
- Site Admin
- Posts: 7348
- Joined: 9 Dec 2007
I have no idea. There is only one way to find out...