You'd have to take it up with whoever makes those ppa's, this page should have contact information for the maintainer of the package.

can you reproduce this with a build from https://builder.blender.org?

• Merge remote-tracking branch 'origin/master' into backdrop_cb
• Remove unneeded optimization.

Not until these features scheduled to land in master. For all i know this branch will go 'nah we'll use something else instead of QEX` next week and i'll have to build that, and then they change their mind again and i have to build that. Branches are highly experimental and don't have the same support from the platform teams that master has. So unless these features enter codereview and it seems likely that it will land in master requiring these libraries pre-build libs will not be made available.

For master on windows i pre-build all libraries for you (you grab them from svn), for this specific branch additional libraries are required which are not available in SVN (and won't be until they are required for master) you either have to turn this functionality off, or build the required libraries your self using the build script in build_files\build_environment\windows\build_deps.cmd however at this point in time there is no support on using this script, if it works for you great! if it doesn't bummer, but i lack the time to help individual users with it.

Don't care who's name is on the commit honestly, i could have committed it my self, but wanted to run it by swerner first , seeing it on the tracker a day later just weirded me out, (not actually upset, but i think 'weirded out' got lost in translation)

I think you misread that, i'm upset you are posting other peoples work. 'thank you is a strange response to that'

I'm slightly weirded out the patch i posted on devtalk for @Stefan Werner (swerner) to validate and help some people out short term, is showing up on the tracker like this

Just in case anyone goes working on this, the bug is that the popup is going out of screen-bounds, the long url it is trying to display is actually what it should be doing.

There are ever going to be 2 possible libdirs ..\lib\win64_vc14 or ..\windows_vc14 (or 4 if ms decides to change the ABI again and we support 2 compiler versions side by side) it'll be faster just to brute force detect it instead of detecting and setting up a msvc working environment

It's not super happy on windows

yeah but you mentioned opening, files created with 'bad dna' are gonna have bad dna, but is the issue still there when you create a new file in a recent version?

up until last week, there was an issue in blenders DNA code for 32 bit, fields were not the size blender though they were, can you still reproduce the issue in files created in a recent build?

fixed in rBf01c71e1d99d9f4ab0b4232215ddcacc90548819

Fixed, but for future reference, build errors do not go on the bug tracker.

Heard people complain on irc that linux is broken as well, seems like the same issue.

I cannot

From the page you used to enter this bug

I'd rather we repro the issue on linux, and run it through a profiler to see whats going on rather than randomly lifting code from other projects based on a hunch.

Can still confirm on windows, different trace than @Antonio Vazquez (antoniov) but still coming out of audaspace though, @Joerg Mueller (nexyon) mind taking a peek here?

>	blender.exe!std::_Tree<std::_Tset_traits<void *,std::less<void *>,std::allocator<void *>,0> >::begin() Line 1187	C++
 	blender.exe!AUD_getSet(void * set=0x000000018b292fe0) Line 58	C++
 	blender.exe!BKE_sound_update_scene(Main * bmain=0x000000008223b958, Scene * scene=0x00000000822716f8) Line 901	C
 	blender.exe!BKE_scene_graph_update_tagged(Depsgraph * depsgraph=0x0000000038e2cef8, Main * bmain=0x000000008223b958) Line 1512	C
 	blender.exe!wm_event_do_depsgraph(bContext * C=0x0000000013b8af78) Line 343	C
 	blender.exe!wm_event_do_refresh_wm_and_depsgraph(bContext * C=0x0000000013b8af78) Line 369	C
 	blender.exe!wm_event_do_notifiers(bContext * C=0x0000000013b8af78) Line 528	C
 	blender.exe!WM_main(bContext * C=0x0000000013b8af78) Line 424	C
 	blender.exe!main(int argc=1, const unsigned char * * UNUSED_argv_c=0x0000000008e5afa0) Line 507	C
 	[External Code]

In T63377#656906, @why is this required (Tysa) wrote:

sorry @LazyDodo (LazyDodo) , first time posting. i updated the main post aswell with everything we figured out so far, hope thats okay.

please do not confirm your own bugs

@Sebastián Barschkis (sebbas), How far off is your branch from this patch set? applying 10 patches may be pushing it, but if all the same stuff is in the branch that'll make testing a little easier.

The game engine has been removed in the next blender version, so there is nothing to be done here.

Hi, while we love to hear these ideas, this is not the right place for them. This website is mainly used to track bug reports and not feature requests. But luckly, there are some other nice solutions you can take, so please use one of the other forms of communication listed below:

ah "it" won't load, you're gonna have to be more specific than this.

https://builder.blender.org has a nightly 2.79 build.

I stand corrected, nice touch by re-creating my insane directory structure :)

I'd like to retract the idea to use the OS dialog then, makes very little sense to maintain two codepaths. time better spend improving the one we have :)

That's an XP screenshot, that's not what it looks like now days, and definitely not a supported os, here's a more recent win7 one

guess suggesting using the OS dialog is heresy?

I don't mind the windows way of doing things actually, they did away with the up button all together

Yeah sure they don't have it anymore, on the other hand you can easily navigate to any part including the parent folder of the path by clicking on it.

That looks scary similar to the stack trace of T62942,

@Mohamed Sakr (msakr) , just commandeer it, and click edit revision in the upper right to fill out the details and proper title

I also say we keep the ".." but if it's selected with other files we just pretend it was never selected?

please run with blender_debug_log.cmd and attach the produced files to this ticket.

Can repro when i turn on the debug heap on windows (kinda like asan, but different, just crashes things, doesn't tell you what is wrong) seems to be coming out of alembic it self, which is perhaps why a blender build with asan didn't find it?

Apple removed support, see D2333 for details.

Tested on Win7 with nvidia and mesa - softwaregl.

Just fix the function so it does what you expect it to do, and fix the one call site that was using it wrong.

putting a diff in a ticket is almost a sure way to have it overlooked, please submit the a diff for review either here or if possible using arcanist

looks like there's already some infrastructure in makesdna.c for such a thing (look for /* a simple dna padding test */), looks like we just need to enable it and incorporate it into the build process and/or unit tests.

Oh my, this is a trickier problem than i thought....

bummer, well keep an eye on T63164 which could be the cause as well

Hate to sounds like an xkcd caricature , but that's generally the way i kill blender whenever it's hung or otherwise real unhappy with the state of things.

urgh there's bugs in the printf generator (had to redo the patch since i already did other work) anyhow pretty sure you got the idea.

i did, it was an ugly hack on top of makesdna to generate the code for the checks

Can't reproduce, but i fixed a buffer overflow on 32 bit regarding studio lights just now, perhaps that was it, see if tomorrows build is better?

There was an update to blender recently to stronger enforce naming of things in addons, so the author probably just has to make a minor update, if you reproduce the issue with any of the plugins we ship with blender feel free to report those ofcourse, but we have no control over 3rd party plugins and we do not track defects for them on this tracker.

Thanks for the report, but this add-on is not developed by Blender, please report the bug to the original author.

@Jacques Lucke (JacquesLucke) i'm not sure what there is for us to triage, the distro build eats files for breakfast, our builds are fine?

please run the blender_debug_log.cmd batch file in your blender folder and attach the generated files.

please run the blender_debug_log.cmd batch file in your blender folder and attach the generated files.

Probably the actual problem

can repro, different callstack though

 	ntdll.dll!0000000076dda365()	Unknown
 	kernel32.dll!0000000076cb1a0a()	Unknown
 	blender.exe!_free_base(void * block=0x000000000e71b650) Line 107	C++
 	blender.exe!free_dbg_nolock(void * const block=0x000000000e71b680, const int block_use=1) Line 987	C++
 	blender.exe!_free_dbg(void * block=0x000000000e71b680, int block_use=1) Line 1011	C++
 	blender.exe!free(void * block=0x000000000e71b680) Line 20	C++
 	blender.exe!MEM_lockfree_freeN(void * vmemh=0x000000000e71b688) Line 159	C
 	blender.exe!BLI_freelistN(ListBase * listbase=0x0000000013f20d98) Line 537	C
>	blender.exe!UI_block_layout_resolve(uiBlock * block=0x0000000013f20d58, int * r_x=0x000000000022f6e4, int * r_y=0x000000000022f704) Line 4704	C
 	blender.exe!ED_region_header_layout(const bContext * C=0x000000000429c928, ARegion * ar=0x000000000e7e90a8) Line 2462	C
 	blender.exe!ED_region_header(const bContext * C=0x000000000429c928, ARegion * ar=0x000000000e7e90a8) Line 2510	C
 	blender.exe!action_header_region_draw(const bContext * C=0x000000000429c928, ARegion * ar=0x000000000e7e90a8) Line 328	C
 	blender.exe!ED_region_do_draw(bContext * C=0x000000000429c928, ARegion * ar=0x000000000e7e90a8) Line 512	C
 	blender.exe!wm_draw_window_offscreen(bContext * C=0x000000000429c928, wmWindow * win=0x0000000013aec428, bool stereo=false) Line 590	C
 	blender.exe!wm_draw_window(bContext * C=0x000000000429c928, wmWindow * win=0x0000000013aec428) Line 724	C
 	blender.exe!wm_draw_update(bContext * C=0x000000000429c928) Line 877	C
 	blender.exe!WM_main(bContext * C=0x000000000429c928) Line 425	C
 	blender.exe!main(int argc=1, const unsigned char * * UNUSED_argv_c=0x00000000006d09c0) Line 507	C
 	[External Code]

@Sebastian Parborg (zeddb) given @Antonio Vazquez (antoniov) stack trace seems to suggest mem issues,try running with ASAN see if that has anything to say about it.

Broken: 2.79b official from distro

Not sure if this is all of them, but at-least these are the ones i remember fixing.

Applies cleanly now, thanks!

patch doesn't apply cleanly, a few errors i can fix, but this many is pushing it, try resubmitting your patch with arcanist using arc diff --update D4602

It's a feature request and it's honestly just Security theater, even if we implement hiding drives in the file browser like explorer does all we'd be doing is giving admins a false sense of security, nothing is stopping a student from running bpy.ops.save_as_mainfile("c:\someplace\whiii.blend"), manually entering paths in many of our UI elements or stop them from using any of the other file-io API's in python, if you don't want users to write files at a certain location it'll have to be enforced OS/filesystem level, not in the 'uhh we'll just hide in the in applications UI, you feel safer now? well you're not but ok....' level.

opencl support has been dropped for mac

do they work when you start blender using the factory starup batch file in the blender folder?

Can't repro on windows either

You reported a legit bug that is in the process of getting fixed, you can sit back and wait for the fix to land, once it does the next days buildbot will no longer crash on your font file :)

They do some expensive cleanup when the refcount hits zero apparently, but i'll be honest, it's not like we'll be calling this 100.000 times a second on a regular basis....

In D4585#104180, @Brecht Van Lommel (brecht) wrote:

I think it's fine to call CoInitializeEx multiple times, the main issue is ensuring we don't call it with different values. I'm not sure there is a good way to automatically ensure it's not called with different values. If someone adds another call to CoInitialize in the future I would hope they read the documentation and then search for any similar calls in the code and verify it's ok.