#250 3DS export segmentation fault

[anne]

On importing a DAE Collada file from Google Sketchup and subsequently exporting to 3DS format, meshlab crashes.

There was an error in libio_3ds.so.

1 0x00007fffd5b283a3 in vcg::tri::io::Exporter3DS<cmesho>::SaveBinary(CMeshO&, char const, int const&, bool ()(int, char const*)) () from /opt/meshlab1.3/meshlab/src/distrib/plugins/libio_3ds.so</cmesho>

I first thought that this was because of lib3ds.a in externals was not properly compiled, but this is not the case. Instead this error is cause by a bug in io_material.h. Over there a string is copied from the textures[] array. The index there is not checked on the maximum size of m.textures.

    static int CreateNewMaterial(SaveMeshType &m, std::vector<Material> &materials, unsigned int index, FaceIterator &fi)
    {
        ...
        int id = (*fi).WT(0).n();
        if((m.textures.size()) && (id >=0) && (id < m.textures.size()) )
            mtl.map_Kd = std::string(m.textures[(*fi).
        ....
   }

Debugging is kind of difficult, I have to say.... 1.) This (big) function is inline, so gdb doesn't show directly the place where it goes wrong. 2.) Just printing to stdout didn't seem to work. So I thought that for the shared library files in the meshlab/src/distrib/plugins directory stdout was redirected to /dev/null. 3.) An assert didn't work either, while libio_3ds.so was updated in that plugin directory. It turned out to be the case that there was one big shared library file "lib3d" compiled out of all the libs that was loaded instead of the individual plugins. An "nm * | grep SaveBinary" revealed the culprit. 4.) If libio_3ds.so doesn't contain all necessary libs (I thought for example first that the textures were not properly protected by a mutex, so I added QMutex), then the .3ds format does not even show up at all in the export options in Meshlab. There is no error whatsoever about not being able to load the plugin.