Hide Forgot
Created attachment 1121403 [details] The exact file I saved off the argyle sweater web site Description of problem: I ran gimp passing it the argyle sweater comic from Feb 5th, 2016 in order to print it. I selected a printer, switched to portrait mode, and printed it. This silly message showed up in the terminal where I ran gimp: tomh> gimp /caliban/cartoons/capslock.gif HMM.... Something strange is happening, malloc and free function pointer changing between invocations in babl. The error only comes out at the time I exit gimp. It fact, if I just start gimp up then exit without any printing, I still get the error. Version-Release number of selected component (if applicable): gimp-2.8.16-1.fc23.x86_64 How reproducible: I tried twice, it happened both times. Steps to Reproduce: 1.Run gimp passing the cartoon as argument 2.Exit gimp 3.See error printed by gimp Actual results: weird error Expected results: no output to terminal where gimp was run Additional info:
Actually, you don't even need the cartoon argument. Just start gimp then exit gimp, the message comes out.
Sorry for the late reply. I have no idea what's happening here, but meanwhile a new version of GIMP (2.8.18) is out, do you still get the same issue?
Hey! I just tried gimp and no "something strange is happening" message appeared. Looks like it is fixed in gimp-2.8.18-1.fc24.x86_64
Thanks for the info!
Too soon :-(. For some reason, at work I do not get the message, but at home I do get it: zooty> gimp HMM.... Something strange is happening, malloc and free function pointer changing between invocations in babl. zooty> type gimp gimp is hashed (/usr/bin/gimp) zooty> rpm -q gimp gimp-2.8.18-1.fc24.x86_64 Some library that isn't updated at home yet maybe? (But I can't find anything that is a different version). It is very weird.
I see a note in here: https://www.bountysource.com/issues/6737344-decompose-is-very-slow-with-a-revealing-console-message That says the babl message depends on the order libraries are loaded, so it may well be different at home and work simply because of ldconfig hash order differences.
More data: 3D apps stopped working on my desktop at work (where gimp was not reporting a problem). I re-ran "ldconfig" to get the nvidia versions of libraries back at the front of the list, and I could run 3D apps again. Also, after running ldconfig, I now see this even on my system at work: tomh> gimp HMM.... Something strange is happening, malloc and free function pointer changing between invocations in babl. So something in the nvidia libraries seem to be causing this. /etc/ld.so.conf.d/nvidia-lib64.conf points to /usr/lib64/nvidia which contains: tomh> ls -R /usr/lib64/nvidia /usr/lib64/nvidia: alternate-install-present libnvidia-fatbinaryloader.so.1@ libEGL_nvidia.so.0@ libnvidia-fatbinaryloader.so.367.35* libEGL_nvidia.so.1@ libnvidia-fbc.so.1@ libEGL_nvidia.so.367.35* libnvidia-fbc.so.367.35* libEGL.so.1* libnvidia-glcore.so.1@ libGLdispatch.so.0* libnvidia-glcore.so.367.35* libGLESv1_CM_nvidia.so.1@ libnvidia-glsi.so.1@ libGLESv1_CM_nvidia.so.367.35* libnvidia-glsi.so.367.35* libGLESv2_nvidia.so.1@ libnvidia-gtk3.so@ libGLESv2_nvidia.so.2@ libnvidia-gtk3.so.1@ libGLESv2_nvidia.so.367.35* libnvidia-gtk3.so.367.35* libGL.so.1@ libnvidia-ifr.so.1@ libGL.so.367.35* libnvidia-ifr.so.367.35* libGLX_nvidia.so.0@ libnvidia-ml.so.1@ libGLX_nvidia.so.1@ libnvidia-ml.so.367.35* libGLX_nvidia.so.367.35* libnvidia-ptxjitcompiler.so.1@ libnvidia-cfg.so.1@ libnvidia-ptxjitcompiler.so.367.35* libnvidia-cfg.so.367.35* libnvidia-tls.so.1@ libnvidia-eglcore.so.1@ libnvidia-tls.so.367.35* libnvidia-eglcore.so.367.35* libOpenGL.so.0* libnvidia-egl-wayland.so.1@ tls/ libnvidia-egl-wayland.so.367.35* xorg/ /usr/lib64/nvidia/tls: libnvidia-tls.so.1@ libnvidia-tls.so.367.35* /usr/lib64/nvidia/xorg: libglx.so@ libglx.so.1@ libglx.so.367.35* No doubt since this is an interaction with the binary nvidia drivers no one will ever be interested in it again (and it never seemed to break anything anyway, it is just a weird message :-).
Parhaps it's something like malloc()/free() being implemented in one of the nVidia libraries, overshadowing the original functions from libc? It's not so much that I'm not interested in helping, but that there's little anybody else than nVidia can really do about it.