Menu
▾
▴
plplot-general
|
From: Torquil M. <to...@gm...> - 2008-02-01 14:27:28
|
Hello, just disregard this if it is the same as the other thread with a=20 segfault and if it does not provide any more information. I get a segfault I get when running the C-example no.1 with the "-save"=20 option: x01c -dev xwin -np -save 1.psc If I comment out plend() in the example, it works fine. I'm using todays SV= N=20 version, built with debugging symbols. The examples are also built with=20 debugging, but gdb gives me no output more than: Program received signal SIGSEGV, Segmentation fault. 0xb7cdd33c in free () from /lib/i686/cmov/libc.so.6 Valgrind gives lots of output, but it is the last one that seems most=20 interesting: =3D=3D32061=3D=3D Invalid free() / delete / delete[] =3D=3D32061=3D=3D at 0x402465C: free (vg_replace_malloc.c:323) =3D=3D32061=3D=3D by 0x40417EF: c_plend1 (plcore.c:1823) =3D=3D32061=3D=3D by 0x40411FB: c_plend (plcore.c:1759) =3D=3D32061=3D=3D by 0x804904D: main (x01c.c:210) =3D=3D32061=3D=3D Address 0x430d4f8 is 0 bytes inside a block of size 131,= 072 free'd =3D=3D32061=3D=3D at 0x402465C: free (vg_replace_malloc.c:323) =3D=3D32061=3D=3D by 0x40417EF: c_plend1 (plcore.c:1823) =3D=3D32061=3D=3D by 0x8048F3B: main (x01c.c:184) There seems to be some problem with freeing memory. It looks like the error= =20 message in sec.4.3.4 in the valgrind manual, here: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.errormsgs =46rom what I can understand (which may be wrong) it is related to freeing = the=20 memory for plsc->plbuf_buffer, but after looking through the code I think i= t=20 will be too complicated for me to track down the error. Best regards, Torquil S=F8rensen |
|
From: Werner S. <sm...@ia...> - 2008-02-01 16:11:34
|
Hi Torquil, same problem for me here - I'll have a look into this. Thanks, Werner On 01.02.2008, at 15:28, Torquil Macdonald S=F8rensen wrote: > Hello, just disregard this if it is the same as the other thread =20 > with a > segfault and if it does not provide any more information. > > I get a segfault I get when running the C-example no.1 with the "-=20 > save" > option: > > x01c -dev xwin -np -save 1.psc > > If I comment out plend() in the example, it works fine. I'm using =20 > todays SVN > version, built with debugging symbols. The examples are also built =20 > with > debugging, but gdb gives me no output more than: > > Program received signal SIGSEGV, Segmentation fault. > 0xb7cdd33c in free () from /lib/i686/cmov/libc.so.6 > > Valgrind gives lots of output, but it is the last one that seems most > interesting: > > =3D=3D32061=3D=3D Invalid free() / delete / delete[] > =3D=3D32061=3D=3D at 0x402465C: free (vg_replace_malloc.c:323) > =3D=3D32061=3D=3D by 0x40417EF: c_plend1 (plcore.c:1823) > =3D=3D32061=3D=3D by 0x40411FB: c_plend (plcore.c:1759) > =3D=3D32061=3D=3D by 0x804904D: main (x01c.c:210) > =3D=3D32061=3D=3D Address 0x430d4f8 is 0 bytes inside a block of size = =20 > 131,072 free'd > =3D=3D32061=3D=3D at 0x402465C: free (vg_replace_malloc.c:323) > =3D=3D32061=3D=3D by 0x40417EF: c_plend1 (plcore.c:1823) > =3D=3D32061=3D=3D by 0x8048F3B: main (x01c.c:184) > > There seems to be some problem with freeing memory. It looks like =20 > the error > message in sec.4.3.4 in the valgrind manual, here: > > http://valgrind.org/docs/manual/mc-manual.html#mc-manual.errormsgs > >> =46rom what I can understand (which may be wrong) it is related to =20= >> freeing the > memory for plsc->plbuf_buffer, but after looking through the code I =20= > think it > will be too complicated for me to track down the error. > > Best regards, > Torquil S=F8rensen > > = ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
|
From: Werner S. <sm...@ia...> - 2008-02-01 19:52:59
|
Hi Torquil, I found the problem. Some months ago changes were made, how the plot commands were recorded (into the memory instead of a file) to be able to replot them. If the plot stream is copied with plcpstrm() also the pointer to this memory is copied (not the memory itself). if you end the copied stream this buffer gets freed. if the first stream is ended, the buffer gets freed the second time->segfault. I didn't write this memory buffer changes, so I don't know if we need the buffer in the new stream, but if it needs to be copied, I suggest that new memory is allocated and the whole memory is copied instead (I also post this to the devel list). Any objections? Regards, Werner PS: Thanks Torquil for finding this bug. Torquil Macdonald Sørensen wrote: > Hello, just disregard this if it is the same as the other thread with a > segfault and if it does not provide any more information. > > I get a segfault I get when running the C-example no.1 with the "-save" > option: > > x01c -dev xwin -np -save 1.psc > > If I comment out plend() in the example, it works fine. I'm using todays SVN > version, built with debugging symbols. The examples are also built with > debugging, but gdb gives me no output more than: > > Program received signal SIGSEGV, Segmentation fault. > 0xb7cdd33c in free () from /lib/i686/cmov/libc.so.6 > > Valgrind gives lots of output, but it is the last one that seems most > interesting: > > ==32061== Invalid free() / delete / delete[] > ==32061== at 0x402465C: free (vg_replace_malloc.c:323) > ==32061== by 0x40417EF: c_plend1 (plcore.c:1823) > ==32061== by 0x40411FB: c_plend (plcore.c:1759) > ==32061== by 0x804904D: main (x01c.c:210) > ==32061== Address 0x430d4f8 is 0 bytes inside a block of size 131,072 free'd > ==32061== at 0x402465C: free (vg_replace_malloc.c:323) > ==32061== by 0x40417EF: c_plend1 (plcore.c:1823) > ==32061== by 0x8048F3B: main (x01c.c:184) > > There seems to be some problem with freeing memory. It looks like the error > message in sec.4.3.4 in the valgrind manual, here: > > http://valgrind.org/docs/manual/mc-manual.html#mc-manual.errormsgs > >>From what I can understand (which may be wrong) it is related to freeing the > memory for plsc->plbuf_buffer, but after looking through the code I think it > will be too complicated for me to track down the error. > > Best regards, > Torquil Sørensen > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
|
From: Andrew R. <and...@us...> - 2008-02-01 20:18:22
|
On Fri, Feb 01, 2008 at 08:52:43PM +0100, Werner Smekal wrote: > Hi Torquil, > > I found the problem. Some months ago changes were made, how the plot > commands were recorded (into the memory instead of a file) to be able to > replot them. If the plot stream is copied with plcpstrm() also the > pointer to this memory is copied (not the memory itself). if you end the > copied stream this buffer gets freed. if the first stream is ended, the > buffer gets freed the second time->segfault. I didn't write this memory > buffer changes, so I don't know if we need the buffer in the new stream, > but if it needs to be copied, I suggest that new memory is allocated and > the whole memory is copied instead (I also post this to the devel list). > Any objections? > > Regards, > Werner > > PS: Thanks Torquil for finding this bug. Werner, I've just been looking at this bug too. We need the buffer - this is what contains the copy of the plot commands for plreplot. The question is should the copied stream have a copy of the buffer, or the actual buffer. The old file buffer code seems to have used the actual file - so by analogy we should have the actual buffer. If this is the case, then we to have a reference counter for the buffer so we only free it once all streams no longer reference it. The original buffer code goes way back before my time with plplot. Does anyone still remember the original intentions? Alan might recall. I'll leave any fix to you so we don't duplicate work. Andrew P.S. I notice plstrm.h contains a plBufOwner variable to mark which stream actually owns a buffer. Unfortunately this isn't used. It also doesn't replace the reference counter because it doesn't stop a copy accessing the buffer after it has been free'd. |
|
From: Werner S. <sm...@ia...> - 2008-02-01 21:57:53
|
Hi Andrew and Torquil, I made the decision to copy the whole (actually the part of the buffer which contains information) buffer to a new memory buffer. Reason is, that there is no obligation to close the stream right after you saved the file. If the programmer decides to work on with both streams, both streams write into the same buffer. Since nowadays memory is not that problem anymore, I decided to copy the buffer. I couldn't test it actually since on Windows there was no segmentation fault, but at least the new version still compiles and runs on Windows. Could anybody (Torquil?) test it, if the changes solve the problems? Regards, Werner > > I've just been looking at this bug too. We need the buffer - this is > what contains the copy of the plot commands for plreplot. The question > is should the copied stream have a copy of the buffer, or the actual > buffer. The old file buffer code seems to have used the actual file - so > by analogy we should have the actual buffer. If this is the case, then > we to have a reference counter for the buffer so we only free it once > all streams no longer reference it. The original buffer code goes way > back before my time with plplot. Does anyone still remember the original > intentions? Alan might recall. > > I'll leave any fix to you so we don't duplicate work. > > Andrew > > P.S. I notice plstrm.h contains a plBufOwner variable to mark which > stream actually owns a buffer. Unfortunately this isn't used. It also > doesn't replace the reference counter because it doesn't stop a copy > accessing the buffer after it has been free'd. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
|
From: Torquil M. <to...@gm...> - 2008-02-01 22:48:41
|
Thanks, I can confirm that this fixes my segmentation fault :-) - Torquil On Friday 01 February 2008, Werner Smekal wrote: > Hi Andrew and Torquil, > > I made the decision to copy the whole (actually the part of the buffer > which contains information) buffer to a new memory buffer. Reason is, > that there is no obligation to close the stream right after you saved > the file. If the programmer decides to work on with both streams, both > streams write into the same buffer. Since nowadays memory is not that > problem anymore, I decided to copy the buffer. I couldn't test it > actually since on Windows there was no segmentation fault, but at least > the new version still compiles and runs on Windows. Could anybody > (Torquil?) test it, if the changes solve the problems? > > Regards, > Werner > > > I've just been looking at this bug too. We need the buffer - this is > > what contains the copy of the plot commands for plreplot. The question > > is should the copied stream have a copy of the buffer, or the actual > > buffer. The old file buffer code seems to have used the actual file - so > > by analogy we should have the actual buffer. If this is the case, then > > we to have a reference counter for the buffer so we only free it once > > all streams no longer reference it. The original buffer code goes way > > back before my time with plplot. Does anyone still remember the original > > intentions? Alan might recall. > > > > I'll leave any fix to you so we don't duplicate work. > > > > Andrew > > > > P.S. I notice plstrm.h contains a plBufOwner variable to mark which > > stream actually owns a buffer. Unfortunately this isn't used. It also > > doesn't replace the reference counter because it doesn't stop a copy > > accessing the buffer after it has been free'd. > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Plplot-devel mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
|
From: Andrew R. <and...@us...> - 2008-02-01 23:13:58
|
On Fri, Feb 01, 2008 at 10:51:25PM +0100, Werner Smekal wrote: > Hi Andrew and Torquil, > > I made the decision to copy the whole (actually the part of the buffer > which contains information) buffer to a new memory buffer. Reason is, > that there is no obligation to close the stream right after you saved > the file. If the programmer decides to work on with both streams, both > streams write into the same buffer. Since nowadays memory is not that > problem anymore, I decided to copy the buffer. I couldn't test it > actually since on Windows there was no segmentation fault, but at least > the new version still compiles and runs on Windows. Could anybody > (Torquil?) test it, if the changes solve the problems? > > Regards, > Werner Werner, Your fix solves the problem for me on Linux. Thanks very much. Andrew |
|
From: <Han...@sh...> - 2008-02-05 09:02:05
|
Hi Werner, The changes you made also fix my problems with the segmentation violation. Thanks, Hans Rijneke -----Original Message----- From: plp...@li... [mailto:plp...@li...]On Behalf Of Werner Smekal Sent: Friday, February 01, 2008 22:51 To: plplot_general; PLplot development list Subject: Re: [Plplot-general] [Plplot-devel] Segfault Hi Andrew and Torquil, I made the decision to copy the whole (actually the part of the buffer which contains information) buffer to a new memory buffer. Reason is, that there is no obligation to close the stream right after you saved the file. If the programmer decides to work on with both streams, both streams write into the same buffer. Since nowadays memory is not that problem anymore, I decided to copy the buffer. I couldn't test it actually since on Windows there was no segmentation fault, but at least the new version still compiles and runs on Windows. Could anybody (Torquil?) test it, if the changes solve the problems? Regards, Werner > > I've just been looking at this bug too. We need the buffer - this is > what contains the copy of the plot commands for plreplot. The question > is should the copied stream have a copy of the buffer, or the actual > buffer. The old file buffer code seems to have used the actual file - so > by analogy we should have the actual buffer. If this is the case, then > we to have a reference counter for the buffer so we only free it once > all streams no longer reference it. The original buffer code goes way > back before my time with plplot. Does anyone still remember the original > intentions? Alan might recall. > > I'll leave any fix to you so we don't duplicate work. > > Andrew > > P.S. I notice plstrm.h contains a plBufOwner variable to mark which > stream actually owns a buffer. Unfortunately this isn't used. It also > doesn't replace the reference counter because it doesn't stop a copy > accessing the buffer after it has been free'd. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-general mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-general |
|
From: Werner S. <sm...@ia...> - 2008-02-05 09:18:13
|
Hi Hans, reading again your very first post, I see that you already described the problem into all its details :). Sorry for that, but the plplot core code is also new to me and I need some time to understand it. Great that it works for you as well. Regards, Werner Han...@sh... wrote: > Hi Werner, > > The changes you made also fix my problems with the segmentation violation. > > Thanks, > Hans Rijneke > > -----Original Message----- > From: plp...@li... > [mailto:plp...@li...]On Behalf Of Werner > Smekal > Sent: Friday, February 01, 2008 22:51 > To: plplot_general; PLplot development list > Subject: Re: [Plplot-general] [Plplot-devel] Segfault > > > Hi Andrew and Torquil, > > I made the decision to copy the whole (actually the part of the buffer > which contains information) buffer to a new memory buffer. Reason is, > that there is no obligation to close the stream right after you saved > the file. If the programmer decides to work on with both streams, both > streams write into the same buffer. Since nowadays memory is not that > problem anymore, I decided to copy the buffer. I couldn't test it > actually since on Windows there was no segmentation fault, but at least > the new version still compiles and runs on Windows. Could anybody > (Torquil?) test it, if the changes solve the problems? > > Regards, > Werner > >> I've just been looking at this bug too. We need the buffer - this is >> what contains the copy of the plot commands for plreplot. The question >> is should the copied stream have a copy of the buffer, or the actual >> buffer. The old file buffer code seems to have used the actual file - so >> by analogy we should have the actual buffer. If this is the case, then >> we to have a reference counter for the buffer so we only free it once >> all streams no longer reference it. The original buffer code goes way >> back before my time with plplot. Does anyone still remember the original >> intentions? Alan might recall. >> >> I'll leave any fix to you so we don't duplicate work. >> >> Andrew >> >> P.S. I notice plstrm.h contains a plBufOwner variable to mark which >> stream actually owns a buffer. Unfortunately this isn't used. It also >> doesn't replace the reference counter because it doesn't stop a copy >> accessing the buffer after it has been free'd. >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> > > > |
|
From: Werner S. <sm...@ia...> - 2008-02-03 14:03:28
|
Hi Jim, > As the author of the memory buffer version, I tried to implement the > functionality of the file buffer version. I thought so, since for the file buffer version it's also not a good solution. Al least if you work with both streams one writes in one buffer. > That said, I think making a > copy of the buffer is the best way to go forward. The purpose of the > plcpstrm call was to copy a buffer so that it could be rendered by a > different device (for example to generate a postscript output from a > plot that is being displayed). > > The advantage to maintaining one plot buffer is to have the capability > to maintain the same plot on two different output devices > simultaneously. > Also a nice idea, what about plclstrm for clone stream? > The name plcpstrm, in my opinion, implies making a copy of the current > state and not linking the two plots. If we do want to maintain a plot > buffer that is linked to multiple device, perhaps a new API call should > be implemented. Regards, Werner |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X