gnuplot @5.4.2: locale-related free() errors on Tiger/PPC

[evanmiller (Evan Miller)]

On program launch I see errors like

gnuplot(12032) malloc: ***  Deallocation of a pointer not malloced: 0xa4c3bac4; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
gnuplot(12032) malloc: ***  Deallocation of a pointer not malloced: 0xa4c3ba54; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug

Setting MallocBadFreeAbort=1 and backtracing in a debugger I see

#0  0x90047dac in kill ()
#1  0x9012d7b4 in abort ()
#2  0x900061f0 in free ()
#3  0x94c372b0 in std::locale::_Impl::_M_install_facet ()
#4  0x94c37598 in std::locale::_Impl::_Impl ()
#5  0x94c37c10 in std::locale::_Impl::_Impl ()
#6  0x90008598 in pthread_once ()
#7  0x94c37c74 in std::locale::_Impl::_Impl ()
#8  0x94c37df4 in std::locale::locale ()
#9  0x94c364a0 in std::ios_base::_M_init ()
#10 0x94c43a9c in std::basic_ios<char, std::char_traits<char> >::init ()
#11 0x01a244f8 in std::ios_base::Init::Init ()
#12 0x0180c92c in _GLOBAL__sub_I_configparam.cc ()
#13 0x8fe15670 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#14 0x8fe0babc in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
#15 0x8fe0ba4c in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
#16 0x8fe0ba4c in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
#17 0x8fe0ba4c in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
#18 0x8fe0d604 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#19 0x8fe02cb4 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#20 0x000068b4 in _start ()
#21 0x00006780 in start ()

Does this look familiar to anyone?

[kencu (Ken)]

That is exactly the ABI error you see with libgcc7 7.5.0+

Try wrapping the bins using legacysupport 1.1

see the cmake port for an example

[evanmiller (Evan Miller)]

Thanks. legacysupport.redirect_bins gnuplot is not fixing the issue. Is it supposed to install a wrapper script? I'm still just seeing a binary at /opt/local/bin/gnuplot.

[kencu (Ken)]

take a look at what the cmake port installs.

[kencu (Ken)]

by the way, with your debugging skills, if you can see a way out of this issue without wrapping bins that would be great.

I think the essential conflict is in libgcc_s.1.dylib, between the one installed by libgcc7.5.0 and the one installed by gcc-4.x into the system roots. A couple of years ago I updated Tiger to libgcc8 for my own use, but the same error occurred so I reverted back to libgcc 7.4.0 which does not have the problem.

In the end though we have to use libgcc 7.5.0+, as gcc 7.4.0 can't build the current icu, amongst other things.

(All of this assuming wrapping bins fixes this, once you sort out how to get it done right.)

[evanmiller (Evan Miller)]

Running env DYLD_LIBRARY_PATH=/opt/local/lib/libgcc gnuplot does fix the issue, so the wrapper approach will work I expect. However the wrapper is not being installed, perhaps because the ${configure.cxx_stdlib} eq "macports-libstdc++" condition is not being met. I will have to dig into it another time.

[evanmiller (Evan Miller)]

I am wondering now if this condition should be removed:

​https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/legacysupport-1.1.tcl#L234

If a binary links to libraries that have this problem, then the binary's choice of stdlib isn't relevant, correct?

[kencu (Ken)]

Probably, the entire macports installation should set DYLD_LIBRARY_PATH=/opt/local/lib/libgcc globally always and skip the wrapping.