cuInit is supposed to return an error code, and we deal with that in exactly that way in case it fails (not crash, but run in a mode not offering cuda acceleration),the problem on your machine, nvidia's code seems to be ruining the stack pointer, it's pretty much impossible to protect your self from that or recover from it.

possibly related to T52439

Looked in the matching source, it's the call to cuInit that makes it crash, @Brecht Van Lommel (brecht) do you have any clever ideas how to trouble shoot this?

I put a build that will produce crash information a while ago here : http://graphicall.org/1222 (not the most recent build, but given all builds seem to crash for you it shouldn't matter that much)

If you find an error in Blender you need to report exactly what fails and how to redo the bug.

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

it's a threading issue introduced in rBfed853ea782211298c902759ec8cd8e455d8b41d

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

eeve is an blender 2.8 feature.

We only support graphics cards with GCN architecture 2.0 and above). To make sure your GPU is supported checkout this Wikipedia page.

never mind, managed to get it to master my self

lgtm, can you push this to master as well?

in the preferences menu go to system and try a different selection method see if that improves things.

In D2716#65628, @Joerg Mueller (nexyon) wrote:

I incorporated all the latest comments. As I understand it, Mac works now. So if everything is ok now, I'll push the patch as soon as I get the ok from @LazyDodo (LazyDodo).

Works for me, the only reason most of the scripts do the weird things they do is to match our currents libs folder 1:1 , but given that is working now, I see no reason not to simplify things

@Arto Kitula (akitula) brought up on irc that he'd rather prefer the headers at ${LIBDIR}/numpy/include/ (i placed 'm in the python folder cause audaspace was already looking there and i was being a tiny bit lazy), I have no strong opinion here, but it's probably good to keep it in the same folder, across all platforms . @Brecht Van Lommel (brecht) any preferences there?

this ticket is about rc1, why are you installing 2.78c?

We are including all redistributables, this is most likely not a blender problem but a corrupted windows installation, to know for sure though

For a successful build this needs some of the numpy headers in the lib folder atleast for windows, pinging @Arto Kitula (akitula) to give this diff a whirl on mac ?

We only support graphics cards with GCN architecture 2.0 and above). To make sure your GPU is supported checkout this Wikipedia page.

remove duplicated message, split up some of the messages so we don't have insanely long lines

can't reproduce on win10/x64 either.. maybe the unpacking somehow got interrupted and it's missing files? try redownloading the .zip and unpacking it again...

i'm also unable to repro on win10/32 bit.... in the future please be *EXACT* from the start on what you are running on so we don't waste a ton of time chasing ghosts.

I'm unable to reproduce on windows7/x64, what os are you on? does it work when you start blender with --factory-startup ?

@Fable Fox (fablefox), don't know how else to contact you, so sadly i'll have to clutter up this ticket . I see you ask for crashdumps quite frequently, the windows version of blender downloaded of our website will *NEVER* make a crashdump, so you can save your self some posts by skipping that step in the future.

i am.

how do i repro this? just opening template.blend didn't do it for me......

every time you see 'If there is a handler for this exception, the program may be safely continued.' just continue debugging, and pass the exception to the app. until it gets stuck at the same spot over and over.

@Lukas Stockner (lukasstockner97) mind taking a peek here?

update: tested with both 2.78c and 2.79rc1, , 2.78c and it does crash instantly there, while 2.79rc1 has no issues. so guess we can mark this one as resolved.

Can't repro either , could be a problem in 2.78c that has since been fixed, can you try the recently released 2.79-rc1 and see if it is still a problem?

yeah with latest master and the broken addon from the mentioned addon hash, it now properly fails , they have been messing with these tests a lot, guess it's fixed....

We only support graphics cards with GCN architecture 2.0 and above). To make sure your GPU is supported checkout this Wikipedia page.

little context, I was testing with artok (mac) and someone on linux, they had the same problem (presets being tested) but the test failed for them , passed on windows.

Please follow our submission template and guidelines and make a complete, valid bug report in english, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

In D2753#65264, @Brecht Van Lommel (brecht) wrote:

In D2753#65258, @Sergey Sharybin (sergey) wrote:

• If we expose this scripts to GNUmakefile, think we'd also need to do same for make.bat

I'll leave that up to @LazyDodo (LazyDodo) to decide, if we intend these scripts to be for platform maintainers it doesn't really matter either way I think.

I think i have been pretty clear on my feelings on this subject, i have no interest in adding this to make.bat *EVER* , this is not something regular users should ever run, if we add it to some common batch file, they will run it, they will have issues with it and i'll have to support it 'cause it's there, so it should work' . I'll happily spend a couple of hours getting a fellow platform dev to get things going, doing this for every user with a compiler installed will be an unreasonable drain on my available time.

lgtm

Yup much better, currently on windows there's a bunch of failed tests, but even with flipping back and forth between the two images i have a hard-time figuring out where the problematic pixels are (added a big red X on one of the images just to be sure it was actually flipping), maybe add a third column with changed pixels highlighted?

Not quite working right on windows, the mouseover scripts have part of the image path with forward slashes, part of it with un-escaped back slashes

tested, i see no issues on windows

https://docs.blender.org/manual/en/dev/render/cycles/gpu_rendering.html#opencl does mention you need a gcn2.0 card. the 7700 seems to be 1.0

i didn't want to delete anything, so i had you rename it, but yeah if you remove/rename/move the 2.78 folder it'll start over with a clean slate.

I'm also still on 7, and can't seem to repro either, but since this seems limited to 2.78 and your system, i'm suspecting there's something wonky in your profile folder, can you try

Harvest is the way it is due to the scripts having to match whatever was in svn when i started, i have no idea how some of these things came to be honestly...

Left a comment in the patch already, i don't like integrating it into make.bat at all, would make it way to accessible, people will use it, and it'll have to support it, given the script has some rather specific requirements, needs admin priv for mklink for python for instance , also i ran into path length issues with llvm in the past. Also when not installed it'll download all the bits of mingw it needs onto the users system with very little signature validation. so yeah..

Couple of things.

In D2724#64721, @Bastien Montagne (mont29) wrote:

Hmmmm… this is way too late to add anything like that in master for 2.79 now… :/

It's been over month with no activity, no idea who normally does modifier code review, @Bastien Montagne (mont29) can you take a peek here?

Cancels almost instantly here, try starting blender with the --factory-startup parameter, to rule out any add-ons causing issues.

from the bug reporting page

What not to report here

if you can share the .blend that is causing issues that might also help

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

2015 isn't supported, cmake should have failed out with, the error 'Currently only Visual Studio 2013 64bit is supported'

@Bastien Montagne (mont29) here's a stackdump

I had no issues getting a stacktrace, seems to be caused by rB880e96dd667aedea17353803bcc5721f3cc34d50 , ID_IS_LINKED_DATABLOCK(ob->data) derefs a null pointer, @Bastien Montagne (mont29) can you take a peek?

build issues do not go in the tracker use irc or the mailing list

Can you try dropping opengl32.dll from http://download.blender.org/ftp/sergey/softwaregl/win64/ into your blender folder and see if the stalling goes away? (remove once you are done testing cause it will slow things down significantly)

That's just a repetition of your previous comment, please provide clear steps on how to reproduce the problem.

In F656004#248, @anonymous (BmB) wrote:

That "right" is the persons left side. look in a mirror sometime. I'm sorry. you are wrong. Stop closing it based on your lack of understandin

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

1. Please watch your tone ( https://developer.blender.org/F655644 )
2. I attached another image, this time with a person.

2.78a is an old version, this bug is already fixed, please update your blender.

This is a general support issue and not a software error we can investigate.

all seems consistent, think you're just confused, here's a handy visualizer.

This is available right now in any 2.78 build from http://builder.blender.org

let me rephrase then.

seems like an nvidia opengl driver bug then..... try upgrading/downgrading your drivers,maybe report it to nvidia?

well there goes that idea... given we're not rendering on the gpu, but it's still stalling the video drivers, try replacing the opengl driver with a software version from

That's weird, you should only have 4101 when rendering on the gpu.... just throwing out random ideas here, there's a known issue with hyperthreading on your cpu [1], try tuning it off in the bios , see if that solves anything

was that a cpu or gpu render?

ID 4101 is tdr timeout, try using a smaller tile size.

Well if you ever do stumble on a reliable repro case, i'd be happy to look at it, for now i don't think there's anything more to be done.

We don't take bugs on 3rd party addons on this tracker, you are probably better served here https://github.com/JacquesLucke/animation_nodes/issues

I don't want to pollute this ticket too much, so i reported the crash on windows in T51967.

found the problem ,just unsure how to fix @Brecht Van Lommel (brecht) help?

tested on windows with a missing userpref.blend , problem is solved,

bisected it to rBfe3fb236970ce30733381ad1ae8b89c55266c517 / D2539 , @Wouter (Waterflames) any ideas here?

You're gonna have to do better, i still have a hard time figuring out how to make it happen