Activity for Andrea Mazzoleni
-
Andrea Mazzoleni modified ticket #310
AdvanceCOMP web page issues
-
Thanks!
-
Likely it's this issue of gcc 14.0 and 14.1. To be fixed in 14.2. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114927 Maybe try with the option -std=c99 or -std=c11
-
Likely PIGZ uses the zip 64 format that is no supported by advzip.
-
AdvanceMAME v3.10 has been released at : http://www.advancemame.it AdvanceMAME/MESS are unofficial MAME/MESS versions with an advanced video support for helping the use with TVs, Arcade monitors, PC monitors and LCD screens. AdvanceMENU is a frontend for the AdvanceMAME, AdvanceMESS, MAME, MESS and any other emulator. They run in Linux, Mac OS X, DOS, Windows and in all the other platforms supported by the SDL library. This is the list of changes: * Alcon / Slap Fight MCU hookup (#116) [arcadez2003]...
-
Advmame crashes with Nvidia drivers (linux)
-
Finally I tried with a NVidea board and I can replicate the issue. You can workaround it with the -nosmp option when starting advmame.
-
SnapRAID v12.3 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Fix potential integer overflow when computing the completion percentage. No effect on the functionality. * Documentation improvements.
-
It's fixed now in github code. I confirm it had no effect other than printing a wrong value. Thanks UhClem!
-
Hi Jon, I checked the code and it's right. It looks like as a false positive warning from the compiler. What compiler and version is it ? Ciao, Andrea
-
Hi ariel, I added the change in git. Thanks, Andrea
-
Hi Marc, Yes, I suppose it would make sense to support them now. The underlying problem is that subvolumes are seen as different filesystems with independent inode spaces. This means that SnapRAID has to keep track of the subvolume ID along with the inode when searching for files by inodes. I'll see what I can do in the next few weeks. But don't hold your breath :) Ciao, Andrea
-
Hi Andy, With the --disable-vc I'm able to replicate the issue. I'm able to work around it using the option -nodisplay_restore that tells AdvanceMAME to not restore the video mode at the exit. But take care that AdvanceMAME still uses the framebuffer, unless you build with --disable-fb. It just uses it without the VideoCore interface. So, I'm not sure that you are really using the SDL. If even with -nodisplay_restore you have problem, try also with -logsync that writes the advmame.log file. Attach...
-
Hi Andy, Have you tried the git version of AdvanceMAME ? It has changes specific for the Raspberry 4. You have to build if from source. Also, try to run AdvanceMAME directly from the command line and not from EmulationStation, and check if the problem is still here. When building AdvanceMAME, you can also use the ./configure --enable-debug, that will report more information after a crash. That info will help to get an understanding of the problem. Ciao, Andrea
-
Hi Andy I tried on my Raspberry 4, and it looks like working well. Can you replicate the issue with the git version of AdvanceMAME on a standard Raspbian ? If yes, in what condition exactly ? I tried from both cmdline, window environment fullscreen, and also in a window (-output window), but everything looks like working. Ciao, Andrea
-
Hi Andy I tried on my Raspberry 4, and it looks like working well. Can you replicate the issue with the git version of AdvanceMAME on a standard Raspbian ? If yes, in what condition exactly ? I tried from both cmdline, window environment fullscreen, and also in a windows, but everything looks like working. Ciao, Andrea
-
Hi guys, I don't have time to add new features or handle minor issues in the project, and opening the Gihub issue will give a wrong message. Ciao, Andrea
-
AdvanceCOMP v2.4 has been released at : http://advancemame.sourceforge.net AdvanceCOMP is a collection of recompression utilities for your .ZIP archives, .PNG snapshots, .MNG video clips and .GZ files. It runs in Linux, Mac OS X, DOS, Windows and in all the other Unix like platforms. This is the list of changes: Fix CVE-2022-35014, CVE-2022-35015, CVE-2022-35016, CVE-2022-35017, CVE-2022-35018, CVE-2022-35019, CVE-2022-35020 Update libdeflate to 1.14
-
CVE-2022-35020 advancecomp: heap buffer overflow via the component inflate()
-
Fixed in github with the commit "Check size of the delta buffer" Here the check of all bugs: am@redstar:/mnt/bag/home/am/data/src/advancecomp/FIXED (master)$ ../advmng -z id0_command_advmng_-z_SEGV_sample_No.1 Corrupt compressed data on id0_command_advmng_-z_SEGV_sample_No.1 [at void throw_png_error():pngex.h:37] am@redstar:/mnt/bag/home/am/data/src/advancecomp/FIXED (master)$ ../advmng -z id2_command_advmng_-z_heap-buffer-overflow_sample_No.1 Corrupt compressed data in IDAT chunk on id2_command_advmng_-z_heap-buffer-overflow_sample_No.1...
-
CVE-2022-35018 advancecomp: SEGV via invalid read memory access
-
Fixed in github with the commit "Check move chunk"
-
CVE-2022-35019 advancecomp: SEGV via invalid write memory access
-
Fixed in github with the commit "Check move chunk"
-
CVE-2022-35017 advancecomp: heap-buffer-overflow in mng_delta_addition() in mng.c
-
Fixed in github with commit "Check move chunk"
-
Fixed in github with commit "Check for truncated end of central directory"
-
CVE-2022-35016 advancecomp: heap buffer overflow in data_dup() in data.cc
-
CVE-2022-35015 advancecomp: heap-buffer-overflow in le_uint32_read() in lib/endianrw.h
-
Fixed in github with commit "Check for truncated end of central directory"
-
CVE-2022-35014 advancecomp: SEGV via invalid read address
-
Fixed in github with commit "Fix not initialized pointer"
-
Yeah, I thought that this should work. Obviously. Do you mean that you intentionally created a new filesystem in the new disk with the same UUID of the old one? SnapRAID uses the filesystem UUID to identify if a disk is replaced. This could have invalidated some assumptions made by SnapRAID. At least, it's not a condition I ever tested. Ciao, Andrea
-
Hi Nick, It's a bit strange, because Snapraid recognizes that your new d5 was the old d2, and it tries to rename it. This means that the filesystem UUIDs of the two disk are the same. How did you initialize and migrate data to the new d5 ? A possible workaround could be to force a UUID change, like with: tune2fs -U random /dev/sdX1 Otherwise, you can also temporarily remove d5 from the snapraid array configuration, run a sync, add it back, and sync again. Anyway, I'll investigate this condition,...
-
SnapRAID v12.2 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Fix build issue with GLIBC 2.36
-
Hi tao, Could you please try the 12.2 RC available at: http://beta.snapraid.it/ It's an equivalent fix, but that keeps compatibility with darwin. If you confirm that it's OK, I'm going to release it. Thanks, Andrea
-
Hi tao, Could you please try the 12.2 RC avatilable at: http://beta.snapraid.it/ It's an equivalent fix, but that keeps compatibility with darwin. If you confirm that it's OK, I'm going to release it. Thanks, Andrea
-
Try removing the #include <sys mount.h=""> line in the file cmdline/portable.h</sys> It's just a try, but maybe it works. Ciao, Andrea
-
It's something that should be fixed in the git code. You can get it from: https://github.com/amadvance/advancemame/ Ciao, Andrea
-
Which gcc version is used ? You can get it with gcc --version
-
The two patches, included in the SUSE src distribution, makes it working. http://download.opensuse.org/update/13.2/src/curlftpfs-0.9.2-61.3.1.src.rpm
-
advancecomp fails to build with GCC 11
-
Just made a v2.3 release to fix this. Ciao, Andrea
-
Hi Kevin, Did that rsync run while sync was in progress the first time you got that error ? If yes, it could be the cause. To replace a disk see: http://www.snapraid.it/faq#repdatadisk Ciao, Andrea
-
Hi Kevin, SnapRAID was thinking that such files were copies of other files, but the hash was not matching the copies. But it's not clear why this happened. Ciao, Andrea
-
Hi Kevin, Try running sync with the --force-nocopy option. Ciao, Andrea
-
SnapRAID v12.1 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Reduce stack usage to work in environments with limited stack size, like MUSL. * Increase the default disk cache from 8 MiB to 16 MiB.
-
Hi saintdev, Yes. It looks like a stack overflow issue. MUSL gives only 128 kB to threads, compared to the typical 1 MB. Please try the beta version at http://beta.snapraid.it/ It reduces a lot the stack usage, and it should fit also in MUSL. Ciao, Andrea
-
Hi Frederik, Ensure to cleanup everything before rebuilding. Like with: make distclean ./configure --enable-debug make gdb --args ./snapraid diff -v run and when it crashes in gdb, type "bt" to get the full stack backtrace. Note also the use of "./snapraid", instead of "snapraid" to ensure to run the one just built. Ciao, Andrea
-
Hi saintdev, Which Alpine version is it ? Does SnapRAID pass the "make check" test after building ? Try also building it with starting with "./configure --enable-debug". It should give even more debug information inside gdb. Anyway, from your gdb log, it looks like that the issues is inside the readdir() function of the musl library. Not sure yet, but it's possible that such function is not thread safe, and crashes due to the use of multithreading added in 12.0. POSIX doesn't require such function...
-
The files are ordered by the physical address of the first sector of the file. This is from version 4.0. It's always better to use --force-realloc than rebuilding the parity, because with force-realloc you keep the file hash already computed. Anyway, before doing so, you can do a sync with the --test-io-stats option that will show some runtime stats on which is the disk that slow down the process. If it's already a parity disk, the reallocation won't have any benefit. Instead, you can try to increase...
-
Hi Chiem, The version 3 is used only with split parity. If not, the version 2 is preferred because it's compatible with older snapraid versions. Anyway, if snapraid needs to use version 3, the migration will happen automatically and transparently. Ciao, Andrea
-
It's gcc 10 that it's more pedantic, and it doesn't like the Linux kernel headers. You can just ignore the warning. I'll disable the warning in the next release.
-
Using git, it's required to delete the older .o files and reconfigure the source. Something like: make distclean sh autogen.sh ./configure make
-
SnapRAID v12.0 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Parallel disk scanning. It's always enabled but it doesn't cover the -m option that still process disks sequentially.
-
Thanks Leifi! I prepared a new RC6 that fixes this Windows issue: http://beta.snapraid.it/
-
Hi, I've prepared a Release Candidate of SnapRAID v12.0 RC5. It's available at: http://beta.snapraid.it/ It supports parallel disk scanning to speedup the initial phase of the 'diff' and 'sync' commands. If you have a spare array, you can help to test this new functionality and see how much does it improve the initial scan phase. (the one called "Scanning..." in sync). Now the disks are all scanned in parallel, and the process should be as long as the longest disk to read. The 'diff' command is safe,...
-
Welcome! Just to be sure I run again all the test suite and everything is OK. Ciao, Andrea
-
SnapRAID v11.6 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * The 'fix' and 'check' command with the -e option now process the whole files that have bad blocks, and not only the block marked bad. This allows to restore the timestamp and to print the paths of processed files and the final state of the files like 'recovered'...
-
Fixed. Thanks!
-
Hi Leifi, It's unexpected the thing you report. On my tests everything looks fine. Could you please make another try ? The sync and scrub behavior is not expected to change, beside a minimal speed increase. Thanks, Andrea
-
Hi, I've uploaded a beta version including the optimization suggested by @UhCleam , and some more. They are here: http://beta.snapraid.it/ Ciao, Andrea
-
Thanks @uhclem, I'm going to look at it.
-
Good to hear!
-
Hi, Yes, -R is dangerous, I'll add a more clear warning in the manual. Instead, -F is safe, as parity is no reallocated. Ciao, Andrea
-
Hi cannondale0815, The second you said. SnapRAID does what it's supposed to do, no changes necessary for the time being. Ciao, Andrea
-
unable to build with gcc 10
-
Hi Erhard F. The latset commit in the github repository should fix it. Specifically the commit f8688cae05799a30cd5337e626a07fa9f004c0a3 Ciao, Andrea
-
SnapRAID v11.5 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Removed the default -march=native to allow to deploy in any machine. * Fixed typos [Andrea Gelmini]
-
Hi dvgeek and others, Please try with: http://beta.snapraid.it/snapraid-11.5.tar.gz I removed the -march=native option. if it works, I'll make it official. Ciao, Andrea
-
Hi dvgeek, Please try with: http://beta.snapraid.it/snapraid-11.5.tar.gz I removed the -march=native option. if it works, I'll make it official. Ciao, Andrea
-
Hi dvgeek, The default build option is now -march=native, meaning that if you copy the executable to a different machine it may not work if the CPU is an older one. You can force a generic CPU with: CFLAGS=-march=x86-64 ./configure Ciao, Andrea
-
Hi Master, You have to download the file https://github.com/amadvance/snapraid/releases/download/v11.4/snapraid-11.4.tar.gz I just regenerated them to fix another version string problem. Note also that running autgen.sh is not required with such package. The two 11.4.zip and 11.4.tar.gz files are generated by github, and they don't contain the version information. To get the version, you need to use the specified .tar.gz, or the git repository. Ciao, Andrea
-
SnapRAID v11.4 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Fix build errors due new gcc 10 default for -fno-common. * In fixing, if a parity is filtered out, don't attempt to recover its size, and proceed without it if missing. * Avoid unnecessary parity read when fixing the parity itself. This improves the 'fix'...
-
For now it's OK. But it's the center of epidemy here... We are locked down in our house, and we can go out only to buy things to eat. But I'm working from home, an I have everything I need, so life is continuing in one way or another. Ciao, Andrea
-
Hi, I'll buy one RPi4 to check, anyway there are reports to have it working. Like this one: https://www.youtube.com/watch?v=yR2_-YYEtmI Maybe it's just a configuration issue. Ciao, Andrea
-
Try running: sudo apt install build-essential Ciao, Andrea
-
Hi Master CATZ, What operating system are you using ? Did you run ./configure ? In case, post the resulting config.log. The problem is that SnapRAID doesn't find any way to set the file timestamp with subsecond precision. At least one of futimens() / futimes() / futimesat() should be present. Ciao, Andrea
-
I checked the code, and the "fix" command just restores the parity to the size stored in the ".content" file. So, unless you used a very old content file, it should not be possible. Another possibility is the "sync" command that if doesn't see any file, it will create an empty parity. Ciao, Andrea
-
Did you used the pre-release 11.4 version ?
-
It's not yet released. You can get a prerelease at: http://beta.snapraid.it/ Ciao, Andrea
-
Hi James, Not really... No much time to invest on that. Ciao, Andrea
-
A crafted png file leads to a heap-based buffer overflow bug in advpng(v2.1)
-
It's fixed in the git repository Thanks for reporting!
-
Hi John, Yes. Hiscore are saved. Save state is manual, not automatic Bezels are supported, but they are the old ones. I mean not the latest format that MAME supports. Ciao, Andrea
-
null pointer dereference in be_uint32_read()
-
invalid memory address in adv_png_unfilter_8( )
-
Thanks for reporting! Latest git version fix that: https://github.com/amadvance/advancecomp Ciao, Andrea
-
Thanks for reporting! Latest git version fix that: https://github.com/amadvance/advancecomp Ciao, Andrea
-
Hi Henry, Yes. You have to use the "even_assign" option. For example, I have: event_assign enter enter or joy_a Try using the "advj" tool to check what are the button names available. Ciao, Andrea
-
Hi Henry, Yes. You have to use the "even_assign" option. For example, I hjave: event_assign enter enter or joy_a Try using the "advj" tool to check what are the button names available. Ciao, Andrea
-
Hi Henry Try using the option "--output overlay", or "--output fullscreen". Ciao, Andrea
-
SnapRAID v11.3 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Fixed handing of Linux devices that have multiple slaves. This affects the smart/list/devices/down commands [Valentin Hilbig]. * The 'list' command in verbose mode prints the full nanosecond timestamp precision. * After writing content files also sync...
-
Hi Matt Both AdvanceMAME and AdvanceMENU takes special care about any change written to files. For example, when AdvanceMENU writes a new state, it first writes a copy, flushes the disk cache, and the rename the new copy over the old one, and flushes again the disk cache. This is not limited to DOS, in fact, in Linux it's something well tested that should work even better than in DOS, as I want my Raspberry to be always bootable even after a hard powerdown :) Ciao, Andrea
-
Hi, It seems that SnapRAID wrote a scrub date in the future. This resulted in a negative time, that due integer overflow got a very high value. A full scrub should remove that value. I'll make a change to prevent that to happen again in future. Ciao, Andrea
-
Hi Michael, Does the sound work again after starting a game and returning to the menu ? Try also playing with "-sound_latency N" and "-sound_buffer M" options with different combination. Like with 0.05 and/or 0.2, instead of the default 0.1. Ciao, Andrea
-
No Willian :) VROC is not supported. Meaning that VROC doesn't help SnapRAID. Ciao, Andrea
-
Hi Jörgen With the present version is not possible to specify an absolute path. You have to put cheat.dat in the directory where other .dat files are installed. I'll fix that in the next version. Ciao, Andrea
-
Hi Borg, SnapRAID doesn't allow to put more than one parity on a single disk. It refuses to start. Any extra space will be unused. This is done for the recovery reason you mentioned, but also for performance. You can instead split one parity in multiple disks. Ciao, Andrea
-
Hi Gufeton, Try deleting these lines: event_assign volume event_assign difficulty Ciao, Andrea
1 >