| 2011-07-21 18:17:49 |
William Good |
description |
The plugin API defines a function which returns a null-terminated array of c-style strings. This memory is allocated (by malloc) in the plugin, and then expected to be freed using free() in the calling code (SoundSourceProxy::something).
This works well where the plugin and mixxx binary are linked to the same C runtime DSO, as is typically the case in Linux, but Windows has more MSVCRT DSOs in the wild than the galaxy has stars (give or take) and different CRT DSOs can use different memory structures in their malloc implementation; this manifests itself in segmentation faults/access violations on plugin usage in Windows. Because we can't guarantee (and shouldn't expect) the two objects to be linked to the same CRT DSO, it's imperative that the unit allocating the memory also be responsible for freeing it; therefore, the plugin API must be modified so that this is the case. |
The plugin API defines a function which returns a null-terminated array of c-style strings. This memory is allocated (by malloc) in the plugin, and then expected to be freed using free() in the calling code (SoundSourceProxy::something).
This works well where the plugin and mixxx binary are linked to the same C runtime DSO, as is typically the case in Linux, but Windows has more MSVCRT DSOs in the wild than the galaxy has stars (give or take) and different CRT DSOs can use different memory structures in their malloc implementation; this manifests itself in segmentation faults/access violations on plugin usage in Windows. Because we can't guarantee (and shouldn't expect) the two objects to be linked to the same CRT DSO, it's imperative that the unit allocating the memory also be responsible for freeing it; therefore, the plugin API must be modified
so that this is the case.
See https://code.launchpad.net/~mixxxdevelopers/mixxx/features_m4a_win7/+merge/67111 |
|
