disParity » Announcements

Version 0.34 beta available

(27 posts)
1 2

  1. Porcus
    Member

    There is nothing under %appdata%\disparity either. (I did search the entire Documents and Settings for “disparity”.)

    The 0.34 seemed to have closed, but maybe I should have fired up a ProcessExplorer to see if it really was. Maybe ... just speculating ... as it closed irregularly, a file handle might still have been up, and 0.21 seems not too happy with files being touched by other applications.

    Anyway, now I did manage to correct everything, and run a successful update (with changes and then one without) under 0.21 with 0.34 open.

    (How I corrected stuff? Seemed it needed some space for temporary files, overfilling my already nearly-full parity drive. So I temporarily moved parity0.dat (unchanged since October) off the drive, ran update, moved back parity0.dat and now everything works (under 0.21), including adds on both drives – it isn't fuller than that.)

    Posted 2 years ago #

  2. Roland
    Roland

    OK, clearly I need to fire up an XP machine here and figure out where those files are going!

    If disParity is idle (i.e. running but not doing any operations), it doesn't keep any files open, so yes I suppose you should be able to successfully run 0.21 at the same time. But I don't recommend this, because if 0.21 makes any changes to the parity data, the running instance of 0.34 won't know about those changes, so if you then tried to, say, run an Update from 0.34, it would probably try to re-apply the same changes that 0.21 just made, and mess up the backup in the process.

    Also, disParity doesn't store any temporary data to the parity drive...unless you've manually changed the temp file location to point there - have you done that? I don't recommend putting the temp folder on the same drive as parity, in fact I should probably detect this case and issue a warning.

    Posted 2 years ago #

  3. Roland
    Roland

    It took a little bit of hunting around but I finally found the files. They seem to wind up here under XP:

    C:\Documents and Settings\<user>\Local Settings\Application Data\disParity

    (Note that both "Local Settings" and "Application Data" are hidden folders so you can't see them by default under Explorer unless you have that option set. Also by default the XP explorer search function does not search under hidden folders.)

    If they aren't here for you, then...I'm stumped!

    Posted 2 years ago #

  4. Klaatou
    Member

    Back on my crash ;)

    So for mp3, I have exactly 3.29 TB for 698 164 Files, 25 993 Folders
    On 18.7 TB 5 234 566 files, 317 918 folders for the entire array.

    For parity space I have a 3TB disk with 1.80TB of parity files (1862 files) when disParity crashed (it must have been close to 80% finished).

    And I have 16GB RAM with only a 1GB ram Hyper-V virtual machine and a google chrome running during the update process.

    I found no error.txt ... but I found errors just at the time the log file was closed in applications events observer (I don't know the exact english name) :

    .NET Runtime ID 1023 :
    Application : disParityUI.exe
    Version du Framework : v4.0.30319
    Description : le processus a été arrêté en raison d'une erreur interne dans le runtime .NET à l'adresse IP 000007FCE685FDFC (000007FCE6780000) avec le code de sortie 80131506.

    And

    Application Error ID 1000 (task category 100):
    Nom de l’application défaillante disParityUI.exe, version : 0.34.0.0, horodatage : 0x50e789f7
    Nom du module défaillant : clr.dll, version : 4.0.30319.18010, horodatage : 0x5038768c
    Code d’exception : 0xc0000005
    Décalage d’erreur : 0x00000000000dfdfc
    ID du processus défaillant : 0x19b4
    Heure de début de l’application défaillante : 0x01cdeec6e37807c7
    Chemin d’accès de l’application défaillante : C:\Program Files (x86)\disParity\disParityUI.exe
    Chemin d’accès du module défaillant: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

    hope it could help ... or maybe it is again a gremlins affair with my Win 8 ....

    Posted 2 years ago #

  5. Roland
    Roland

    According to my limited French, that message translates roughly to "the process was stopped by an internal error in the .NET runtime" with an error code of 80131506.

    I looked it up. There is some info here:

    http://stackoverflow.com/questions/4367664/application-crashes-with-internal-error-in-the-net-runtime

    Here's the top response there:

    "That's a nasty one, ExecutionEngineException. Starting with .NET 4.0, this exception immediately terminates the program. The generic cause is corruption of the state of the garbage collected heap. Which in turn is invariably caused by unmanaged code. The exact location in code at which this exception is raised isn't helpful, the corruption usually occurred well before the damage is detected.

    Finding the exact cause for this is going to be difficult. Review any unmanaged code your service might be using. Suspect environmental problems if there is no obvious candidate, misbehaving malware scanners are notorious. If it repeats very poorly then suspect hardware problems like soft RAM errors."

    DisParity doesn't use any unmanaged code, except for the few direct calls it makes in to the Win32 subsystem to query how much RAM the system has installed and how much is currently in use.

    Apologies if you said so already, but has this happened more than once? Can you try starting the rebuild over and see if it happens again? Unfortuantely that's the only suggestion I can think of at the moment.

    Posted 2 years ago #

  6. Klaatou
    Member

    I found this sort of explanation but I don't know what a unmanaged code can be ;)

    No, I don't remember having such a program stop before. Only for my first try of the first disParity beta but I had an error message I saw some one had once too. Nothing like this crash long after the process began.
    Of course I plan to start a new rebuild but it is very long, the crash was after 3 days and the disks are working a lot, I will give them and to me a little rest before.
    Actually I'm a bit busy away from the computer and as I would like to be a bit farer in my files sorting and path name length reduicing before to do the rebuild it will not be this week I think.

    Posted 2 years ago #

  7. Roland
    Roland

    "Unmanaged" code is code that was compiled from a language like C or C++ directly to CPU instructions. Everything before .NET was unmanaged. In unmanaged code, the programmer is typically response for allocating and freeing his own memory. You have to be careful with pointers and buffers to make sure you don't accidentally write to the wrong part of memory, which can cause random crashes or other bizarre behavior.

    disParity is written in C#/.NET, which is also referred to as "managed" code, meaning that it runs inside the .NET environment which handles all memory management for you. In managed code it is very difficult to cause memory corruption bugs, so this person is basically saying that the error (which indicates memory corruption) can really only be caused by a bug in unmanaged code. (.NET apps often still have unmanaged pieces in them, like old .DLLs written in C++ that you still want to use.)

    In disParity's case there are no unmanaged components, so this problem must be caused by something else. There are some hints online that there may actually be a bug with the garbage collector in .NET 4 (the piece that frees up memory that your program is no longer using) that could also be causing this. I'm still poking around.

    Posted 2 years ago #

RSS feed for this topic

1 2

Reply

You must log in to post.