Blender crashes when exporting to "deep" folders?

I’m running Blender 2.45 under OS X 10.4.10 and I’ve been having problems exporting files to folders that are 5 or more levels deep (from my “desktop” folder) and Blender gives me the “spinning beach ball” for a couple seconds and then crashes. This happened when I exported to both .FBX and .OBJ. It didn’t happen when I exported directly to the desktop. Anyone experience anything like this before? Is this a limitation of Blender under OS X?

I don’t get this problem myself but I know someone who tried Blender out recently and it did something like this. I couldn’t figure out what was causing it. It was working fine at the beginning but then after a while, the guy came to me saying it was just crashing and sure enough no matter if I did save as or export, Blender would just hang and then crash.

It did this just choosing the option though so I don’t know if it was trying to navigate too many levels. Do any of the folders have odd characters in them like forward slashes etc?


t did this just choosing the option though so I don’t know if it was trying to navigate too many levels. Do any of the folders have odd characters in them like forward slashes etc?

No, I don’t think so. I very rarely use characters like that (a carry over from old DOS and UNIX days). The reason I think it has to do with how deep the folders were is because when I tried to export directly to the desktop, it worked fine.

iám on OSXintel as well, Tiger 10.4.10

I did a test for you: when trying to save to an deep hirarchie, blender
chrashes immidiately when i climb down to the folder.
So your bug is confirmed, dunno where it comes from

To check, just create a deep folder-hirarchie and in blender go for example
to save-dialog and step down the folders, it will chrash.

I don´t experienced other problems so far.
One thing to say is blender does not like special characters.
Especially ä,ö etc. are shown wrong.
Relicts from the old ( UNIX- ) days ? Or maybe the lenght of
the concerned code exeeds a given number of characters.
We should report this to the bugtracker, would you do this ?


Thanks for confirming this and no I didn’t use any weird characters (I’m using a US english keyboard if that matters). Where is the bugtracker and do I need an account to log a bug?


I did some testing too (Ubuntu Studio feisty fawn, blender 2.44 from the official repositories) and it seems the problem does not depend on the number of nested folders but overall path length.

This works:
This crashes:
console says:
*** stack smashing detected ***: blender-bin terminated
Aborted (core dumped)

18 nested folders work

doesn’t work:

Can anyone confirm this?
Seems like some kind of buffer overflow. Blender crashes as soon as I navigate into a folder. Hope this helps to identify the problem.


Hi, confirmed and debugging, the odd thing is that the line is only 100chars, the real limit is 160, so it shouldnt be crashing. I commented out this block and it works…

Its crashing in BLI_diskfree

    if(sfile->type==FILE_UNIX) {
        df= BLI_diskfree(sfile->dir)/(1048576.0);

        filesel_statistics(sfile, &totfile, &selfile, &totlen, &sellen);
        sprintf(naam, "Free: %.3f MB   Files: (%d) %d    (%.3f) %.3f MB", df, selfile,totfile, sellen, totlen);

        glRasterPos2f((float)xco, 5.0);
        BIF_RasterPos((float)xco, 5.0);    // texture fonts
        BIF_DrawString(G.font, naam, 0);

bug fixed, BLI_diskfree had a 100char limit, now has a 160 char limit and wont crash if its more.
also fixed another bug where you could crash blender with names longer then 160 chars in the dir text entry.

This is not a python problem - it happens with any file selector

Yea, its a character limit thing. I did a test on windows xp, and got the same beachball then blender just closing(I modifiyed the look of xp). I noticed that the folder path went on to the second row on the save as dialog, where the name is supposed to go. I am guessing that as long as the directory stays in the top row, you should have no trouble.

Cool Cambo. Gotta love it when a bug is fixed before I can even figure out how to report it! I’m guessing the next Blender release won’t be until next year, right? Now that I know what causes the bug, I guess I’ll have to start being a bit less verbose in my folder names. :wink:

Yea. I am wondering though if they could get another release out before the end of the year. I started blender in may, when 2.43 came out. Since then, 2.44 and 2.45 have been released. Based on that, it may be possible for a end of year release. I really cant wait. I am having trouble in 2.44 and 2.45 with importing .obj models (they dont import the texture), so I am still using 2.43. But each release that comes out I will try, and then just re-install 2.43 if I need to.

I will upload a new SVN-trunk-build for OSXintel with this bugfix today.

I will try to do a fix for the standard 2.4.5-release-version soon.

Edit: fixed SVN:


Thanks Jens, but unfortunately your build requires Python 2.5 and I’m sticking with Apple’s “official” Python 2.35 for now.

Where is the problem.
You can got Python 2.5 easily or mail me so i can try to do a
Python 2.3 Version, just have to compile it.
But i like Python 2.5 much better because it supports more scripts
and is faster. You should consider Python 2.5 from, it is
a simple binary-install and you can use it side by side with old Python.
The Blender-version just loads the one it is compiled with.

I have a corrected build for OXSintel available.
It means an Blender 2.45 / Python 2.3 release version with just this dir-length-fix.
An 2.45 / Python 2.5 would be no problem.
Should i publish this, or not so urgent ?

The actual SVN at GRAFICALL has it included !