Followup
| Message |
 |
- Date: 2010-06-10 05:30
- Sender: Leif Andersen
- I have added the stack trace of the crash.
| - Date: 2010-06-10 20:51
- Sender: Leif Andersen
- After a bit more investigating, I believe the bug is traced to the *win variable declared at the beginning of void wm_event_do_handlers(bContext *C) in wm_event_system.c. When this function is called in python, win->eventstate is null, which is causing the segfault.
| - Date: 2010-06-11 03:53
- Sender: Leif Andersen
- Well...I have a pseudo fix, which works part of the time... (depending on what the user does before typing in the command), in wm_event_system.c, wrap the starting on line 1728, wrap the assertions in if statments, like this:
if(win->eventstate) {
win->eventstate->prevtype = -1;
win->eventstate->prevval = 0;
win->eventstate->prevclicktime = 0;
}
}
}
if(win->eventstate) {
/* unlink and free here, blender-quit then frees all */
BLI_remlink(&win->queue, event);
wm_event_free(event);
}
Also, I noticed another problem, occasionally the segfault will be caused in wx_event_system.c, line 1651, because &sa->totrct is null, causing problems in the wm_event_inside_i() method.
| - Date: 2010-06-13 02:07
- Sender: Leif Andersen
- Just an update...this bug causes blender to crash in background mode because the main wm doesn't have a ghostwin, and when it get's to wm_match_do, it reaches the 4th case, because there is a current wm, and the old wm was in the file. However, the problem was that neither the current, nor the old wm had a ghostwin, so when it tried to compare them, a Null pointer exception was raised. (in GHOST_SetWindowUserData()). Now, it does work to put that in an if statement:
if(win->ghostwin) {
GHOST_SetWindowUserData(win->ghostwin, win); /* pointer back */
}
However, unlike the fixes proposed in the last update, this doesn't work, either the data become entirely erased, rather than loading the default .b.blend file, or a segmant failure occurs when dealing with RNA stuff. I'm looking into that, but I have a feeling it has something to do with improper matching in the above listed code. Also, putting this in if statements doesn't break blender when the window is visible, which makes sense, as the ghostwin wouldn't be null.
| - Date: 2010-06-15 20:42
- Sender: Leif Andersen
- Okay, another update. I was talking with Diego Borghetti, and he said that it is expected for blender to crash in background mode, because supposedly there is no window manager. Although, I recently realized that doesn't make sense, because that function is called before the script is run to setup the context, however, it does work there because it falls into the first two cases in wm_window_match_do, which doesn't compare ghostwins. Either way, if it is decided that the wm module shouldn't be available for blender in background mode, it should be actually removed in that case, rather than simply throwing a segfault. Also, there are several functions in the wm module that would make sense even if there is no visible window available.
Finally, the fix I proposed (changing line 1658 in wm_event_system to if(&sa->totrct != NULL && wm_event_inside_i(event, &sa->totrct)) {
), doesn't work, while &sa->totrct being null catches a lot of cases, it isn't necessarily null, but could be in a space the program doesn't have access too. To duplicate this:
1. Start up blender in fg mode (with the above mentioned changes).
2. In the python console type:
a. bpy.ops.render.render()
b. bpy.ops.image.save_as({"window":bpy.context.window}, filename="<somename>", directory="<directoryname>") (note that this will complain that the context is wrong).
c. Run bpy.ops.wm.read_homefile()
It will segfault, because &sa->totrct isn't null, but it does cause problems.
| - Date: 2010-06-15 20:44
- Sender: Diego Borghetti
- Hi,
We have two things here, for one side the WM module can't be use in background mode (I think, because we don't have any window there), but on the other side, we need some of the function that I see in the wm for background mode two, like save or open a file.
Campbell, can you take a look at this ?
Thanks,
- Diego
| - Date: 2010-06-15 21:27
- Sender: Leif Andersen
- Hmm...I think the window manager contains more than just a list of all of the windows, due to blender being a mutated version of MVC, rather than MVC in it's strictest sense. But there is a high probability I could be wrong with that. (I just notice that a bunch of operations are in the windowmanager/ section of the codebase, rather than being somewhere else, such as editors/ ).
Also, pertaining to bpy.wm not being available in background mode, some of the calls seem to be available, for example:
bpy.ops.wm.memory_statistics()
| | |
|
