Welcome to Fractal Forums

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

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.  :hmh:

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.

Is this happening with the latest version of Mandelbulber?

I am asking because I experienced qt5widget.dll crashes with all programs using qt5 version lower than 5.6.

Mandelbulber is now using that qt5 version and I have no problems at all anymore.

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

an uninitialized pointer ?

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..

Interesting.. I was wondering if there was a 'magic' number - guessing maybe 4.
FYI tho, using 350x200 (7:4) the program would crash about once a day - not 5 times as with 400x225.
Using 800x600, or any of the preset sizes, I think it was crashing daily too. Can't remember for sure if I checked debug info. If I did, then it was the same "No Symbol file loaded" message.

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.

Ok.. It may be there was something screwy with my Symbols set up.
Still don't know what Symbols Mandelbulber would've been looking for (or was it VS looking for Symbols?), but:

I found in VS a facility to acquire symbols packages, either via Microsoft Symbol Server or by downloading all symbols. I chose the latter and they ended up in C:\Users\username\AppData\Local\Temp\SymbolCache, which is kinda like where I remember messing with symbol files before. Not sure "Temp" is a real good place...

Anyway, since then and with any amount of colour and position tweaking I haven't had a single crash. yay
So good so far. I guess we'll have to wait and see for the rest..............

In case anyone happens to be interested and this has anything at all to do with Mandelbulber regularly crashing, it is possible to download Windows Symbol packages from https://developer.microsoft.com/en-us/windows/hardware/download-symbols

Will keep you posted, should the need arise.

Thanks to all.

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.

64 bit, in line with my OS architecture.

Will look into Valgrind, if deemed necessary.

Thanks.

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.

One thing seems to reproduce it often for me is messing with Material colours - maybe during rendering or not, I'm not sure.
Usually I do that on the Fractal Tab, tho central main UI dialogue for the same thing does the same.
It might have something to do with Save Material as.. Who knows, but I do like to save minor colour changes as I go - usually overwriting previously saved Material file.

I thought about Optimisation buttons on Rendering engine Tab. Sometimes gives unexpected results (tho I haven't checked exactly what to expect) and makes rendering way slower than typing 1, 0.1 or 0.01 into the Raymarching step mult. field.

Combine Optimisation with Material edit?

Anyway; What does it mean for VS to 'pass on' an exception to the program being debugged?
A mess, I suspect, but; does anyone know?

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?

Materials stored in materials folder has nothing to running of the program. The program doesn't load that files when runs, except when user use "Load materials..." option. If you use load option to add material to the project, then material data is saved inside settings file for the fractal. Even if you delete all files from materials folder, the program will still run properly and your collection of settings files will be still rendered properly.
About your lost material 1.fract file, the program will not restore this file.

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.

Today I have found the error which probably caused crashing of the application. Using valgrind memory checker tool I have try to do different things with the program. I was very long process (program runs 100 times slower than normally), but I have finally generated and logged crash of the program. When the problem window was being resized then image preview was also resized (freeing and allocating of memory) and at the same time image preview was updated by rendering thread. It caused writing the data to memory which was no longer allocated.
I have fixed the problem using QMutex which prevents from reallocating of memory during updating of preview. Now I cannot crash the program in the same way.

Why not just avoid reallocation? isn't it "better" to allocate a sufficient amount of memory for all cases at the beginning?

It's not possible in this case until image preview resolution can be different and zoom in the window also can be changed. Going in that way the program should allocate RGB8 bitmap for 65636x65536x400% bitmap. It's not reasonable :)