#0 0x00007fc446fb77f4 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #1 0x00007fc446fb496d in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #2 0x00007fc446fb533e in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #3 0x00007fc446fb5a4e in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #4 0x00007fc446f9e1bf in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #5 0x00007fc446fb593b in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #6 0x00007fc44713cfa8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #7 0x00007fc446f99927 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #8 0x00007fc446f9ac41 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #9 0x00007fc446f9b163 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #10 0x000000000182bd5e in ?? () #11 0x00000000012b3a0a in ?? () #12 0x00000000012b6f65 in ?? () #13 0x00000000012bdf46 in ?? () #14 0x00000000012c5138 in draw_object () #15 0x00000000012ae2b1 in ?? () #16 0x00000000012b07ac in view3d_opengl_select () #17 0x00000000012a7e3c in ?? () #18 0x00000000012a8f3b in ?? () #19 0x00000000012a9634 in ?? () #20 0x00000000011c3585 in ?? () #21 0x00000000011c4a7a in ?? () #22 0x00000000011c4e71 in ?? () #23 0x00000000011c5386 in ?? () #24 0x00000000011c5825 in wm_event_do_handlers () #25 0x00000000011bc908 in WM_main () #26 0x00000000011615c3 in main ()
@Darwin Yip (darwin) I think immVertex2s will be useful in the future, so let's keep it! Did not use it here because switching between 2f and 2s was tricky to get right. Would like to replace these arrows with a high-quality bitmap one day.
@Mike Erwin (merwin) Since immVertex2s is no longer used, should the function definition be removed in order to keep consistency across the the project?
Formatting looks a little weird. Use tabs and make sure indentation matches surrounding code.
Hm, right, it was too spammy in headless mode - fixed now.
Addressed color line issue and updated deprecated functions to use imm.
Hi Joey, can you elaborate on "better options" Im working on a network rendering addon for blender at the moment, would be nice to know what the plans are regarding this feature.
I'm pretty sure it has something to do with my configuration, but I already restored the setting, un-installed the program and deleted the AppData. I don't know how to fix it.files.zip
Chris Lee's screenshot shows the abrupt falloff clearly,
and I attest that the problem persists in recent builds (e.g. Jan 18th 2017) of Blender 2.78,
and even on the Experimental Branch build of Jan 15th. (Mac OS)
Is the mesh generated from a script?
Make sure you don't use any of the addons, start blender with --factory-startup command line argument to be sure. Also ensure you don't use any handlers (pre/posr render and similar).
I can confirm the issue with your file, but I can't reproduce it. How did you get a polygon like that? Looks like it has issues with vertex order.
Few things here:
- That log is not reporting a crash at all, afaict blender is closing OK (error reported are from python, maybe some wrong order in Cycles RNA classes unregistering, or something else - 'destructor' of classes in python are notoriously unreliable :/ ). Anyway, this is no crashing.
- We would for sure need a file to reproduce the issue, though in that case if error is not even consistently reproducible with a same given file, it sounds a bit like a wild goose chase.
- Nonetheless, we do not accept to privately handle cases of non-open files, nor any kind of NDA etc. That kind of thing is not compatible with an open project development.
- Random crashes could also be caused by mere memory allocation fault. That would depend on amount of RAM, amount of available RAM, amount of RAM fragmentation, etc. E.g.: do crashes happen immediately after start of computer, or only after hours of work?
- Other thing with very complex files that can go wrong in current blender, especially if some physical simulations are involved, is is concurrency between rendering process and usual UI refresh - Please try to lock the interface during render (little lock icon next to the display selector, in Render panel) and see whether it crashes still happen.
There's very little to go on here, try using something like process monitor ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) to see what's going on.
Thanks for at least looking at this.
It's unfortunate that the 'no significant' change has broken the code. With the awesome new features in the works for v2.80 I hope that version works again.
The Logitech MX Anywhere 2 is not an uncommon exotic device and I do use the Logitech software and drivers for it already. I am no C/C++ programmer but I'd be willing to try to compile Blender from source to see what happens if the v2.77 code for device input was grafted back onto the v2.78 branch but I would need to know where to look.
@Joey Ferwerda (TheOnlyJoey) I report bugs since 3 years and a half now. I must say this bug is really nasty. I already tried to reproduce it by replacing every mesh with a subdivided cube with similar polycount and every texture with a generated one of same resolution. But even without changing polycount, object count and texture count and sizes, the file just wouldn't crash anymore.
As I said in my comment, most of the time, only reopening the same file, without changing anything is enough to workaround the bug. So I don't see how a file could be submitted here. Maybe let @Bastien Montagne (mont29) and @Sergey Sharybin (sergey) decide if the crash log is enough to find the bug?
The behavior of .active with rows that share the same parent can be an issue that can show up elsewhere in the UI, so adding user interface tag too.
We currently don't accept bug reports or fixes for BI which are not regressions.
As the behaviour is consistent between current and previous versions, I can not consider this as a bug.
It seems that there has been no significant changes to the input code between the mentioned blender versions, this is also not testable for the developers since they don't own this particular device.
Update initialization code to version 2.78.4 and make it ready to include in version 2.79.
Though netrender is currently unmaintained and removed for 2.8, this seems to be a simple fix.
Seems not to be a direct regression.
As the netrender is currently unmaintained, will be removed in 2.8 and can be worked around, closing this.
In 2.8 this will be replaced with better options.
Closed for being duplicate of T49846
Can you please provide us with a (legally obtainable) model which has this behaviour?
We can not test this if we don't have the same files.
We appreciate the report, though this is not a bug.
Thanks for reporting,
Cycles uses memory for renders, this is normal behaviour.
This is not a bug but rather a question regarding how the program works.
Please ask these types of question on a community like Blender Artists.
Thanks for the report.
Assigning to Pablo for Pabloïfication.