Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2003-02-05 22:08:55
|
On Wed, 5 Feb 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > Pretty sure, I had to cvs update to see your changes. The configure line > after upgrading to the last autools versions and running bootstrap.sh: > > > make maintainer-clean > > ./bootstrap.sh > Running aclocal (GNU automake) 1.7.2... done > Running libtoolize (GNU libtool) 1.4.3... done > Running autoheader (GNU Autoconf) 2.57... done > Running automake (GNU automake) 1.7.2... done > Running autoconf (GNU Autoconf) 2.57... done > > ./configure --enable-octave --enable-dyndrivers --disable-static > --with-double --prefix=3D/usr/local/test I confirm the segfault problem found by Joao: I just did an absolutely fresh checkout from cvs, rm -rf $prefix/*; =2E/bootstrap.sh; configure (followed Joao's configure options of --enable-octave --enable-dyndrivers --disable-static --with-double ); make; make install; cd $prefix/lib/plplot-5.2.0/examples/c; make Then ./x01c -dev xwin produces a segfault. In fact if you ./x01c with no options or the -debug option there is an immediate segfault with no output whatsoever. I then used valgrind ./x01c and there are an enormous number of messages (n= ot there before) involving invalid reads, etc. So there is clearly a memory management problem with the new code. Rafael, you should be able to reproduce this bug if you do exactly what I did since we have very similar systems. Joao's choice of configure options may be important or there may be something left over in your build or install location that makes it work on your system but not on ours. But the fresh checkout and the above rm -rf should take care of that potential difference between us. Once you confirm the bug, I highly recommend valgrind --gdb-attach=3Dyes --num-callers=3D100 ./x01c to quickly debug the memory management problem. Good luck! Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting softwar= e package (plplot.org). __________________________ Linux-powered Science __________________________ |
|
From: Rafael L. <lab...@ps...> - 2003-02-06 10:58:01
|
* Alan W. Irwin <ir...@be...> [2003-02-05 16:56]: > If you had different configure options than Joao and me but are too tired > to re-run the test, could you at least tell us what those configuration > options are? I might find they work on my system which would imply the bug > is configure option dependent and not autotools version dependent. Just a comment on this: what makes me think that the problem is related to the autotools is the original report by Joao: * João Cardoso <jc...@fe...> [2003-02-05 21:06]: > | > (gdb) run -dev xwin > | > Starting program: /usr/local/test/lib/plplot5.2.0/examples/c/x01c > | > -dev xwin > | > > | > Program received signal SIGSEGV, Segmentation fault. > | > 0x0806a46e in lt_dlsym (handle=0x807b0e0, > | > symbol=0xbfffef50 "DEVICE_INFO_pstex") at ltdl.c:3330 > | > [...] The bug has been caused by a call to the function lt_dlsym in ltdl.c, more precisely when it is called with argument "DEVICE_INFO_pstex". Of course, this is related to my last changes in the code. However, I can hardly see what I am doing wrong, since I cannot replicate the bug. I tend to believe that it is related to version problems in the Autotools. That said, I really hope that this is a configuration option problem, which would be easier to fix... -- Rafael |
|
From: Maurice L. <mj...@ga...> - 2003-02-05 18:27:03
|
Rafael Laboissiere writes: > * Rafael Laboissiere <lab...@ps...> [2003-02-04 22:37]: > > > c) At build time (not configuration time), a small C program dlopen the > > <driver>.c files, get the symbols described above and write the > > associated device entries in <driver>.rc (or whichever name). > > Just to make things a bit more concrete, here is the design that I have in > mind. I will take the ps.c driver as an example. The following global > variables will be defined in the driver source: > > char* DEVICES_ps = "ps:psc"; > > char* DESCRIPTION_ps = "PostScript File (monochrome)"; > int TYPE_ps = plDevType_FileOriented; > int SEQNUM_ps = 29; > char* SYMTAG_ps = "psm"; > > char* DESCRIPTION_psc = "PostScript File (color)"; > int TYPE_psc = plDevType_FileOriented; > int SEQNUM_psc = 30; > char* SYMTAG_psc = "psc"; > ... > What do you think? I accept suggestions for better variable names. If you are introducing variables into the global name space (i.e. accessible via "extern"), at least give them a plplot-specific introducer like "pl_" or even better "pldev_". -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Rafael L. <lab...@ps...> - 2003-02-05 19:34:02
|
* Maurice LeBrun <mj...@ga...> [2003-02-05 12:25]: > If you are introducing variables into the global name space (i.e. > accessible via "extern"), at least give them a plplot-specific introducer > like "pl_" or even better "pldev_". Point taken. The functions exported by the the drivers have the "plD_" prefix. Would that be appropriate? Should I use something like: plD_DESCRIPTION_<dev> with the variable name in upper case to emphasize the fact that they are exported variables? -- Rafael |
|
From: Maurice L. <mj...@ga...> - 2003-02-05 20:07:05
|
Rafael Laboissiere writes: > * Maurice LeBrun <mj...@ga...> [2003-02-05 12:25]: > > > If you are introducing variables into the global name space (i.e. > > accessible via "extern"), at least give them a plplot-specific introducer > > like "pl_" or even better "pldev_". > > Point taken. > > The functions exported by the the drivers have the "plD_" prefix. Would > that be appropriate? Should I use something like: plD_DESCRIPTION_<dev> > with the variable name in upper case to emphasize the fact that they are > exported variables? Sure. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Rafael L. <lab...@ps...> - 2003-02-05 20:19:23
|
* Maurice LeBrun <mj...@ga...> [2003-02-05 14:05]: > Rafael Laboissiere writes: > > * Maurice LeBrun <mj...@ga...> [2003-02-05 12:25]: > > > > > If you are introducing variables into the global name space (i.e. > > > accessible via "extern"), at least give them a plplot-specific introducer > > > like "pl_" or even better "pldev_". > > > > Point taken. > > > > The functions exported by the the drivers have the "plD_" prefix. Would > > that be appropriate? Should I use something like: plD_DESCRIPTION_<dev> > > with the variable name in upper case to emphasize the fact that they are > > exported variables? > > Sure. I just committed the change for the extern DEVICE_INFO_<driver> variables. They are called now plD_DEVICE_INFO_<driver>. -- Rafael |
×
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