Logo by rathinagiri - Contribute your own Logo!

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

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Did you know ? you can use LaTex inside Postings on fractalforums.com!
 
*
Welcome, Guest. Please login or register. November 29, 2020, 11:56:25 AM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: [1] 2   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: 2.08-3 Constant Crashing - "No Symbol file loaded"'  (Read 1603 times)
Description: info gleaned from Visual Studio 2015 'debug'
0 Members and 1 Guest are viewing this topic.
CCV
Navigator
*****
Posts: 73


« on: August 19, 2016, 05:53:57 AM »

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

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

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.
Logged
blob
Strange Attractor
***
Posts: 272



« Reply #1 on: August 19, 2016, 01:00:39 PM »

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.
Logged
Buddhi
Fractal Iambus
***
Posts: 895



WWW
« Reply #2 on: August 19, 2016, 07:05:49 PM »

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
Logged

3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #3 on: August 20, 2016, 01:09:43 AM »

an uninitialized pointer ?
Logged

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
CCV
Navigator
*****
Posts: 73


« Reply #4 on: August 20, 2016, 03:02:55 AM »

Is this happening with the latest version of Mandelbulber?

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..
Logged
CCV
Navigator
*****
Posts: 73


« Reply #5 on: August 20, 2016, 03:24:20 AM »

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

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.
Logged
CCV
Navigator
*****
Posts: 73


« Reply #6 on: August 21, 2016, 04:57:07 AM »

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.
« Last Edit: August 21, 2016, 05:09:53 AM by CCV, Reason: OS specific » Logged
CCV
Navigator
*****
Posts: 73


« Reply #7 on: August 21, 2016, 07:51:25 AM »

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.
Logged
Buddhi
Fractal Iambus
***
Posts: 895



WWW
« Reply #8 on: August 21, 2016, 08:46:30 AM »

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

CCV
Navigator
*****
Posts: 73


« Reply #9 on: August 21, 2016, 09:28:53 AM »

Do you use 32-bit or 64-bit version of application?

Actually I analyze the program with valgrind .,

64 bit, in line with my OS architecture.

Will look into Valgrind, if deemed necessary.

Thanks.
Logged
CCV
Navigator
*****
Posts: 73


« Reply #10 on: August 22, 2016, 05:13:00 AM »

Actually I analyze the program with valgrind to find any potential problem...

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.


* VS.jpg (125.39 KB, 606x404 - viewed 125 times.)
Logged
CCV
Navigator
*****
Posts: 73


« Reply #11 on: August 25, 2016, 11:17:00 AM »

I cannot reproduce this problem. I have tested it a lot without any crash (with 64bit).

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?


* VS-pass.png (232.14 KB, 357x166 - viewed 263 times.)
Logged
CCV
Navigator
*****
Posts: 73


« Reply #12 on: September 06, 2016, 06:53:33 AM »

I cannot reproduce this problem. I have tested it a lot without any crash (with 64bit).

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?
Logged
Buddhi
Fractal Iambus
***
Posts: 895



WWW
« Reply #13 on: September 06, 2016, 08:06:34 PM »

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

CCV
Navigator
*****
Posts: 73


« Reply #14 on: September 07, 2016, 04:14:10 AM »

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.
Logged
Pages: [1] 2   Go Down
  Print  
 
Jump to:  


Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.212 seconds with 29 queries. (Pretty URLs adds 0.01s, 2q)