END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

First I want to say how great it is to now have the recovery option available after each crash. Yay! Thanks people. 
Mandelbulber always was prone to randomly crash, in my experience, usually just when things get interesting.. 

Lately, much more frequently - since I started working at 400x225 scale which is equivalent to 16:9 ratio and small enough to render relatively quickly. I wouldn't think the size matters much, but crashes are about 5 times more often with it. 

The "Symbol file" mentioned is always in relation to Qt5Widgets.dll (Version 5.06.1.0; C:\Program Files\Mandelbulber v2 win64\Qt5Widgets.dll) On Win 10, Version 1607 (OS Build 1439.51), btw..

Don't know if this is any help but, further information:
Unhandled exception at 0x00000000016B5D90 (Qt5Widgets.dll) in mandelbulber2.exe: 0xC0000005: Access violation reading location 0x0000000000000008. Twice.
Once at 00000000013D5D90.
I don't know the first thing about VS, nor about how much info is useful. A couple more examples with added details from 'disassemble':

Exception thrown at 0x00000000015E5D90 (Qt5Widgets.dll) in mandelbulber2.exe: 0xC0000005: Access violation reading location 0x0000000000000008.

00000000015E5D90  mov         r12,qword ptr [r13+8]

Unhandled exception at 0x0000000001425D90 (Qt5Widgets.dll) in mandelbulber2.exe: 0xC0000005: Access violation reading location 0x0000000000000008.

0000000001425D90 4D 8B 65 08          mov         r12,qword ptr [r13+8] 

In any case, whenever I checked, I noticed it's always the "mov" thing. Makes me wonder if it has to do with the amount of navigating I do in small scale.. ?? Crashes happen during rendering tho, at different times. Once I find what I want and increase size to 1600x900 it renders no problem at all - so far.

One more thing, tho it appears to have been a once only glitch:
Unhandled exception at 0x00007FFE990773E3 (ntdll.dll) in mandelbulber2.exe: 0xC0000374: A heap has been corrupted (parameters: 0x00007FFE990CF6B0).
Whatever "a heap" may be, I not long ago did a full clean reinstall of Mandelbulber (with AV disabled) in case of corrupt installation.

Thank you for your attention and for such a great program. Any help much appreciated.

Thanks you for reporting this problem. I will try to reproduce this on my PC by setting this image resolution. Maybe there is some problem when image resolution is not divisible by 8

Yes, afaik. In case I didn't make it clear enough, it's Mandelbulber version 2.08-3 with Qt5Widgets.dll Version 5.06.1.0.

I haven't used it for quite a while, but have kept the program up to date. I get notifications of updates for a few things from SourceForge  Crash rate now is usually once a day, on average. Guessing it was something the same previously..

Additional point:
Adjusting colours only in Edit Material is causing the same form of crash, but seemingly more quickly or more often.
So, whatever the "mov" details mean, I have no idea..

Allowing rendering without making any such adjustments seems to work ok.
Except once, with the error -
Unhandled exception at 0x00007FFF0EEA73E3 (ntdll.dll) in mandelbulber2.exe: 0xC0000374: A heap has been corrupted (parameters: 0x00007FFF0EEFF6B0).

00007FFF0EEA73E3 EB 00                jmp         RtlReportCriticalFailure+99h (07FFF0EEA73E5h)

Turns out, VS was able to debug that one so that Mandelbuber continued to run. yay


The only reason I have Visual Studio, as I now recall, was so as to replace the default Symbols Cache used to generate Windows (diagnostic) log files. One in particular being mostly illegible, and 'problem with symbols' being a suggested cause.
Now I can't find where I did that. Might've been wiped out by a recent Win10 upgrade.

So, fwiw, may I ask;
What is the location and name of the file from where this program would normally load Symbols? In Win 10, that is.

Thank you.

I cannot reproduce this problem. I have tested it a lot without any crash (with 64bit). 32-bit bit version sometimes crashes, but probably because of lack of system memory (2GB limit for application).
Do you use 32-bit or 64-bit version of application?

Actually I analyze the program with valgrind to find any potential problem (uninitialized pointers, writhing out of array, wrong memory allocation). It's very slow process so will take some time.

Seems to me, Valgrind isn't suitable for Windows - not yet anyway. The is a variety of debuggers available for Windows. Perhaps a bit out of my league and I have no clue which would be best suited here.

Had a good run yesterday, but back to frequent crashes today. The one I caught was of the same sort.
Turns out Symbols are required for the debbugging, not for "the binary" to run.

So, if I understand the attached image properly, the symbol problem comes about because Qt5Widgets.dll isn't built with the required debugging information. Does that seem correct to you?

Anyway, because the size of the image (225 in height) does seem to contribute to frequency of crashes, I changed it to 224 and then 228. Seems to be working better with those numbers, for now.. We'll see about later.

Cheers.

As an update on this problem:
I can't reproduce it now either.

I crashed my computer (don't ask) and had to resort to an Image Restore from before the issue became so serious.
I think the what may have caused it was my renaming one or two "material" files in a no doubt misguided attempt to restore default colours of "material 1". Whatever the case, seems something I did screwed up the internal workings of the program.

Looks like what I should've done is use "Save as.." to 'rename' my colour changes displayed as "material 1". Material 1 then is displayed in it's default state. At least, it seems so to me now and that is the state of the program at present and I haven't had a crash for days. A few early on, but not the same type and nothing consistent enough to be worth reporting.

Just curious about how to fix the mess I made if it hadn't been resolved by the image restore.
If I deleted "material 1.fract", would the program then restore it on next launch?

Thanks, Buddhi, for the clarification.

I am, in that case, totally clueless as to what might've been behind the program crashing so badly - so often, that is. I can see how restore from image might affect the state of the program, but not improve it beyond the state it was in at the time of image backup. It used to always crash once a day, on average, but lately not all. Mystery to me.

Anyway, when Mandelbulber is first launched it automatically loads settings.fract which includes the original default colours for Material 1. From there, if you so wanted, you could use Save material as... to restore it to Materials folder.
That is what I did, but with some name changes so as not to overwrite colour changes I had made to what otherwise displayed as Material 1.

I guess that's the end of it, for now. So, bye and thanks again to all.