The crash bug of LibLoad/LibFree calls is caused by dangling pointers left in the material caching maps by the KX_BlenderSceneConverter::LinkBlendFile function.
The crash itself pops out in RAS_BucketManager but the bucket manager looks fine.
Disabling material caching in the ui solves the issue.
The pointed values are freed at KX_BlenderSceneConverter::FreeBlendFile (~1374 and ~1391)
At that point the two caching maps m_mat_cache and m_polymat_cache might still contain pointers to the same values but the maps are not cleaned up.
The pointer to the materials are created by RAS_MaterialBucket* material_from_mesh (BL_BlenderDataConversion.cpp ~911), starting from KX_BlenderSceneConverter::LinkBlendFile.
And there is the second issue. When KX_BlenderSceneConverter::LinkBlendFile links the scene, it creates a temporary scene, KX_Scene* other, whose content is merged with the active scene. The data pointed by other is then released and I didn't find any place where the value "other" might have been stored for later use.
The problem is that when the temporary scene is created, that KX_Scene* value looks to be used as the key for the cached materials (in the BL_BlenderDataConversion.material_from_mesh function). If I'm right (big if) and that "other" is not some way kept somewhere, there is no way for the cached materials to be accessed by key.
Initially I thought that the correct thing to do - in the diff below - was to remove the cached values associated to the temporary scene when the pointer was released.
But that also solves the crash problem of the dangling pointers. This oddity makes be believe that simply removing the "other" key from the caching maps is like disabling the entire caching system.
Another approach - and probably the correct one - could be to do as KX_BlenderSceneConverter does in its MergeScene function, that is re-linking also the cached materials.
I'd like to hear some thoughts on this stuff before to start looping through maps of maps of lists of tuples trying not to destroy everything.
The diff just marks the key points of the problem.