Repeatedly calling LibLoad and LibFree on the same library / blend will cause a crash. #37920

New Issue

Jared Smith · 2013-12-22T18:29:41+01:00

Jared Smith commented

2013-12-22 18:29:41 +01:00

System Information
LinuxMint Release 15
Kernel Linux 3.8.0-30-generic
MATE 1.6.0

Memory: 3.8 GB
Processor: Intel Core 2 CPU 64bit

NVIDIA Driver: 310.44
GPU: GeForce 8600 GTS

Blender Version
Building from trunk at current commit.
commit b2fdc591c3
Date: Fri Dec 20 01:38:07 2013 +0100

Short description of error
Alternating between LibLoad and LibFree on the same library / blend file will result in a segmentation fault. This has happened for both async and non-async loading. The callstacks for both methods appear to be different though. I have two sample projects. The first one is my current project where I'm using async loading to load the library. This results in a segmentation fault as a result of what I think is a deleted material not being removed from the m_mat_cache in the KX_BlenderSceneConverter. The other sample file is just a scene that loads / unloads a second blend file without async load. This results in a different callstack which seems to be fairly random in where the segfault occurs.

Exact steps for others to reproduce the error
Sample Files:
bge-sandbox-master_libfree-crash.zip - https://drive.google.com/file/d/0BynKqQ0GhlWWUjNqNE9fWDZWbWc/edit?usp=sharing
cube_libfree_test.zip - https://drive.google.com/file/d/0BynKqQ0GhlWWNndIek1ZR1h3U0k/edit?usp=sharing

bge-sandbox-master_libfree-crash:

Extract and run the bge_test_01.blend from within blender (snap the scene camera to current camera by pressing 0)
Repeatedly press PAD7 to load and unload the level.
Eventually a segfault will occur.

cube_libfree_test:

Open the test.blend in blender and run.
Wait until the running script produces a segfault.

**System Information** LinuxMint Release 15 Kernel Linux 3.8.0-30-generic MATE 1.6.0 Memory: 3.8 GB Processor: Intel Core 2 CPU 64bit NVIDIA Driver: 310.44 GPU: GeForce 8600 GTS **Blender Version** Building from trunk at current commit. commit b2fdc591c36cf5125eaa528b7f735c3c4393d390 Date: Fri Dec 20 01:38:07 2013 +0100 **Short description of error** Alternating between LibLoad and LibFree on the same library / blend file will result in a segmentation fault. This has happened for both async and non-async loading. The callstacks for both methods appear to be different though. I have two sample projects. The first one is my current project where I'm using async loading to load the library. This results in a segmentation fault as a result of what I think is a deleted material not being removed from the m_mat_cache in the KX_BlenderSceneConverter. The other sample file is just a scene that loads / unloads a second blend file without async load. This results in a different callstack which seems to be fairly random in where the segfault occurs. **Exact steps for others to reproduce the error** Sample Files: bge-sandbox-master_libfree-crash.zip - https://drive.google.com/file/d/0BynKqQ0GhlWWUjNqNE9fWDZWbWc/edit?usp=sharing cube_libfree_test.zip - https://drive.google.com/file/d/0BynKqQ0GhlWWNndIek1ZR1h3U0k/edit?usp=sharing bge-sandbox-master_libfree-crash: 1. Extract and run the bge_test_01.blend from within blender (snap the scene camera to current camera by pressing 0) 2. Repeatedly press PAD7 to load and unload the level. 3. Eventually a segfault will occur. cube_libfree_test: 1. Open the test.blend in blender and run. 2. Wait until the running script produces a segfault.

Jared Smith commented

2013-12-22 18:29:41 +01:00

Changed status to: 'Open'

Jared Smith commented

2013-12-22 18:29:41 +01:00

Added subscriber: @JaredSmith

Jared Smith commented

2013-12-27 18:12:59 +01:00

I've uploaded a new version of the archive with the test files that includes a scene that uses async load along with some logs I gathered with valgrind. I'm new to this, but from the time I've spent looking at this, it looks like the memory heap is being corrupted. The crashes seem to be occurring in random places at different times. Valgrind seemed to turn up a number of what I think are false positives, but a few related to the allocation and freeing of scenes.

https://drive.google.com/file/d/0BynKqQ0GhlWWRlR4VHFXMDZpbXc/edit?usp=sharing

I'll also post the logs here for easier access:
test.blend:
http://www.pasteall.org/48291
http://www.pasteall.org/48292 (--leak-check=full)

test_async.blend:
http://www.pasteall.org/48293
http://www.pasteall.org/48294 (--leak-check=full)

Btw, the valgrind logs were generated with the blenderplayer. I know the start up path is different than the embedded player, but the results seem to relatively be the same.

I've uploaded a new version of the archive with the test files that includes a scene that uses async load along with some logs I gathered with valgrind. I'm new to this, but from the time I've spent looking at this, it looks like the memory heap is being corrupted. The crashes seem to be occurring in random places at different times. Valgrind seemed to turn up a number of what I think are false positives, but a few related to the allocation and freeing of scenes. https://drive.google.com/file/d/0BynKqQ0GhlWWRlR4VHFXMDZpbXc/edit?usp=sharing I'll also post the logs here for easier access: test.blend: http://www.pasteall.org/48291 http://www.pasteall.org/48292 (--leak-check=full) test_async.blend: http://www.pasteall.org/48293 http://www.pasteall.org/48294 (--leak-check=full) Btw, the valgrind logs were generated with the blenderplayer. I know the start up path is different than the embedded player, but the results seem to relatively be the same.

Jared Smith commented

2013-12-27 19:44:00 +01:00

Just another update. I wanted to get some cleaner output from valgrind. I made a test scene that uses user input so I could LibLoad async and LibFree the test blend file just once and then close blenderplayer. I've updated the test files again and linked a copy of the valgrind log.

https://drive.google.com/file/d/0BynKqQ0GhlWWb3lhOGhaNkhzYlU/edit?usp=sharing

test_input_async.blend:
http://www.pasteall.org/48295

There's one error that sticks out atm, the only invalid write in the log.
http://www.pasteall.org/48296

Just another update. I wanted to get some cleaner output from valgrind. I made a test scene that uses user input so I could LibLoad async and LibFree the test blend file just once and then close blenderplayer. I've updated the test files again and linked a copy of the valgrind log. https://drive.google.com/file/d/0BynKqQ0GhlWWb3lhOGhaNkhzYlU/edit?usp=sharing test_input_async.blend: http://www.pasteall.org/48295 There's one error that sticks out atm, the only invalid write in the log. http://www.pasteall.org/48296

Campbell Barton was assigned by Ton Roosendaal

2013-12-29 20:04:07 +01:00

Jared Smith commented

2013-12-30 02:14:31 +01:00

cube_libfree_test.zip

Attaching the test files and logs to bug.

[cube_libfree_test.zip](https://archive.blender.org/developer/F58916/cube_libfree_test.zip) Attaching the test files and logs to bug.

Campbell Barton commented

2013-12-30 04:15:08 +01:00

This is a bug in freeing linked data when the library object has no material.

issue is material is not seen as being from the library so the MaterialRenderBucket is not freed when freeing the library.

This is needed since the mesh is referenced from the material.

This is a bug in freeing linked data when the library object has no material. issue is material is not seen as being from the library so the MaterialRenderBucket is not freed when freeing the library. This is needed since the mesh is referenced from the material.

blender-admin commented

2013-12-30 05:49:13 +01:00

This issue was referenced by blender/blender-addons-contrib@6a473305af

This issue was referenced by blender/blender-addons-contrib@6a473305af22468abfc4c4f8f3002dc0a97fffd7

blender-admin commented

2013-12-30 05:49:13 +01:00

This issue was referenced by 6a473305af

This issue was referenced by 6a473305af22468abfc4c4f8f3002dc0a97fffd7

Campbell Barton commented

2013-12-30 05:50:35 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2013-12-30 05:50:35 +01:00

Campbell Barton commented

2013-12-30 05:50:35 +01:00

Closed by commit 6a473305af.

Closed by commit 6a473305af.

Campbell Barton commented

2013-12-30 08:13:34 +01:00

Changed status from 'Resolved' to: 'Open'

Campbell Barton reopened this issue

2013-12-30 08:13:34 +01:00

Campbell Barton commented

2013-12-30 08:13:34 +01:00

re: opening, bge-sandbox-master_libfree-crash.zip still crashes,

while cube_libfree_test.zip works correctly on my system.

Seems these are 2 unrelated bugs.

re: opening, bge-sandbox-master_libfree-crash.zip still crashes, while cube_libfree_test.zip works correctly on my system. Seems these are 2 unrelated bugs.

Jared Smith commented

2013-12-30 17:36:25 +01:00

I can still produce a seg fault with test.blend and test_async.blend in Debug. Although when I have valgrind attached with the --track-origins=yes --error-limit=no options and optimizations and in-lining disabled for the build as recommended on the wiki, it doesn't seem to seg fault (I waited about 3-4 mins or so).

Valgrind did give me the following error when running test_async.blend.
http://www.pasteall.org/48359

The callstack from the seg fault in test_async.blend (running with blenderplayer) appears to be the same each time.
http://www.pasteall.org/48360

I can still produce a seg fault with test.blend and test_async.blend in Debug. Although when I have valgrind attached with the --track-origins=yes --error-limit=no options and optimizations and in-lining disabled for the build as recommended on the wiki, it doesn't seem to seg fault (I waited about 3-4 mins or so). Valgrind did give me the following error when running test_async.blend. http://www.pasteall.org/48359 The callstack from the seg fault in test_async.blend (running with blenderplayer) appears to be the same each time. http://www.pasteall.org/48360

blender-admin commented

2014-01-22 14:50:01 +01:00

This issue was referenced by blender/blender-addons-contrib@51c32ac199

This issue was referenced by blender/blender-addons-contrib@51c32ac1996f3e6794b1fe29d4e03b10360f9455

blender-admin commented

2014-01-22 14:50:01 +01:00

This issue was referenced by 51c32ac199

This issue was referenced by 51c32ac1996f3e6794b1fe29d4e03b10360f9455

Campbell Barton commented

2014-01-22 14:51:03 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue