On Sat, 29 Sep 2012, Frederic Koehler wrote: > On Sat, Sep 29, 2012 at 3:40 AM, Marc Balmer <m...@msys.ch> wrote: >> Am 29.09.12 03:29, schrieb Jon Trulson: >>> On Fri, 28 Sep 2012, Marc Balmer wrote: >>> >>>> for patch 1: don't roll your own strfunctions, use strlcpy or so >>> >>> I'm inclined to apply this - strlcpy isn't available on all systems >>> (on linux, requires bsd lib I think). In addition, strlcpy also does >>> not permit overlapping buffers, based on a google search. Was >>> valgrind detecting overlapping buffers? Did it fix a problem? > > Hi, yes, per the commit comment this fixes a valgrind message [these > buffers are also obviously overlapping, just look at the code]. Using the > "obvious" implementation of strcpy there are no issues with the code, > but by the standard it's not guaranteed [and apparently implementations > do in fact do strange clever things.] > >> >> Well, linking with libbsd is no problem, it is available on all Linux >> distributions. An alternativ could be to include your own copy of the >> strlcpy function from e.g. OpenBSD, which is really small. I would opt >> for a solutions that used zillions of time over a hand-made kludge. >> >> Or, maybe try to fix the underlying problem, if there is one. >>
Ok, I'm going to apply this one. strlcpy() has the same limitations regarding overlapping copies that strcpy does so that's no solution. Also, it's not really a kludge - it's the recommended way to handle these situations. Here's a few links I found on google related to the dangers of overlapping strcpy's. http://meta-coding.blogspot.com/2011/07/overlapped-strcpy.html http://stackoverflow.com/questions/4823664/valgrind-warning-should-i-take-it-seriously The Internet has spoken - I have seen strange problems before with overlapping copies - especially when the copies are 'optimized' to copy a 'word size' at a time for performance (4 bytes or 8 bytes at a time). >>> >>>> for patch 2: hunk 1 and 3 are not needed >>>> >>>> >>> >>> Yeah, not sure about this one either... Confused. >>> >>> Marc says 1 and 3 are not needed, but if you omit them, then 2 cannot >>> work otherwise. I wonder if this is the real problem? Is this on a >>> 64b machine? I wonder if this patch just moved the problem somewhere >>> else? >>> >>> Comments on either of these? > > This is on a 64-bit machine. Opening the help window works fine the > first time [and > their are no valgrind messages], but after closing it and opening it > again the program > segfaults, and there are a lot of valgrind messages about using freed > memory. If you > don't close the help window, it works fine and sends the help window > back to the top. > I'd expect the same issue on a 32-bit machine, but if it isn't there > then we could > investigate further. > > So this fix seemed to be the correct change, because it sends the code > back on the > "there is no help window path" which works correctly. I tried repeatedly on a 32 bit box - opening multiple helps - no core. But... I checked my XiG sources on this file (since this seemed a familiar problem), and lo and behold, I fixed this exact problem in an identical way back in 2002 :) So, I'm applying this one too. Thanks. -- Jon Trulson The Higgs Field is what make atoms matter. -- Tom L. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
