Dear developers:
I am currently under Ubuntu 18.04.
When my blender 2.8 crashes, should I consider send bug report?
Is there any log to send with bug report to allow developers locate the issue?
Dear developers:
I am currently under Ubuntu 18.04.
When my blender 2.8 crashes, should I consider send bug report?
Is there any log to send with bug report to allow developers locate the issue?
Is there any log to send with bug report to allow developers locate the issue? Like calling stack?
So we have to tweak the command line to run with -d
every time to get the log? But my crash already happen, I donât have a way to reproduce that.
Maybe a more general way to get some text output for crash only will be better? Require user to add -d
option is kind of impractical.
Very important is, that the bug is reproducible, that is, not occurring on a random basis. It is fine if the bug randomly happens for example 1 out of 10 times you perform some operation. However if the bug randomly happens without any clear steps leading up to it, then it is unlikely developers will be able to fix the bug.
Exactly, that is why a crash report without -d
is important, with the aid of the call stack, developers will be able to locate those random bugs
. Instead of already crash, then let user -d
start the program again.
Have you checked if a file named blender.crash.txt (or something.crash.txt) appeared anywhere? For example /tmp/. Last time I saw it was not very complete (reduced debug info) but less is nothing.
IMO default should be with lots of debug, and then swap to speed options when approaching stable release.
I saw that, when I put the -d
to my default start option, it says âlog in /tmp/blablaâ from my terminal. (Donât know if it will generate if I start without -d
).
I figured out a way to make it crash, 100% success on my machine, will file a report later.
Last time I saw it was not very complete (reduced debug info) but less is nothing.
Yes, information is very limited.
What is IMO and how to enable that? I will enable that and generate my bug report.
In My Opinion. About how compiling should be made, and how the buildbot should work too. Use all (âthose not absurdly slowâ) debug options by default for development, and only disable them some time before shipping the final version (so optimization bugs can be found then, and the final version is fast).
Agree, maybe team should allow us to download a verbose
version with many debugs defaultly turned on.
I am start with -d
every time already, but /tmp/blender.crash.txt has very limited information.
I will try @jenkm 's link to add more options to see if I could get more in detail logs.
You can find options like âdebug-allâ or âverboseâ; not sure what exactly theyâre doing.
But, there is no reason to run Blender in a debug mode all the time, developers always ask for exact steps to reproduce the bug. So apparently the crash log itself is useless.
I will try provide more details to developers instead of guessing what they do.
I just got a crash when I went to remove double vertices on quite a simple geometry, even though I removed double vertices a few moments before on basically the same duplicated geometryâŚ
Iâm curious, how do the developers ever fix these crashes which are pretty impossible for normal users to report?
EDIT: Ha, that one was actually repeatable, so I made a bug report. But promptly after that I got a crash on a vertex merge, and that one I havenât been able to repeat.
I was talking about compile options, beta software with debug helpers is more useful than without.
Iâve had issues with blender rendering. I have a blend file that links in hundreds of models, some of them very dense. When I hit F12, the memory usage goes all the way up to 12GB so, rendering with GPU is expected to crash because I only have 8GB of vram. The thing is, blender doesnât stop the render and give you the CUDA memory error that you always get, it just closes. However, when I switch to CPU to render, I get the same behavior, the only difference is it crashes at random points, and sometimes it doesnât crash at all. I would expect blender to not crash when using the CPU to render because I have 64GB of ram, but it does⌠maybe take forever, but not crash. Also, as I increase the amount of samples, the render crashes earlier. So, at 1 sample it might not crash, but as soon as you start going up in sample count, itâs more possible for it to crash and to crash sooner.
I added the -debug option and I am getting a memory allocation error. I wanted to save the crash report, but I canât find the crash log. Any idea where itâs saved?
Is this something I should report? If it is, how should I report this? Like I said, the main blend file links in hundreds of models and textures, so it wouldnât be a matter of just attaching one blend file.
So I just had a crash in 2.82.7 upon rendering an image the second time without restarting Blender first.
So I checked this:
https://docs.blender.org/manual/es/dev/advanced/blender_directory_layout.html#temp-dir
And also searched my entire drive for anything â*crash.txtâ, but found nothing.
What OS are you using? Blender on Windows will finally be shipping with a crash log produced automatically upon crashing in version 2.90.