Recent changes to bugs

#207 pkg-config includedir is broken

Atri — Thu, 09 May 2024 16:23:18 -0000

I am one of the maintainers of plplot on openSUSE, I noticed this and we fixed this for our packages with the following patch:

Index: plplot-5.15.0/pkgcfg/plplot-template.pc.in
===================================================================
--- plplot-5.15.0.orig/pkgcfg/plplot-template.pc.in
+++ plplot-5.15.0/pkgcfg/plplot-template.pc.in
@@ -1,6 +1,6 @@
-libdir=@LIB_DIR@
-includedir=@INCLUDE_DIR@
-drvdir=@LIB_DIR@/plplot@PLPLOT_VERSION@/drivers
+libdir=@CMAKE_INSTALL_FULL_LIBDIR@
+includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
+drvdir=@CMAKE_INSTALL_FULL_LIBDIR@/plplot@PLPLOT_VERSION@/drivers

 Name: PLplot @PC_SHORT_NAME@
 Description: Scientific plotting library (@PC_PRECISION@@PC_LONG_NAME@)
Index: plplot-5.15.0/CMakeLists.txt
===================================================================
--- plplot-5.15.0.orig/CMakeLists.txt
+++ plplot-5.15.0/CMakeLists.txt
@@ -95,6 +95,8 @@ endif(POLICY CMP0086)
 # install trees.
 set(PROJECT_NAMESPACE PLPLOT::)

+include(GNUInstallDirs)
+
 option(USE_WRITEABLE_TARGET_TEST_PREFIX "Option to test library and executable targets which have both writeable and (ALIASed namespaced) read-only versions of their targets in the build tree and namespaced read-only targets in the install tree.  This test prepends a prefix to the writeable version of the target name so as a result any such target referred to in the build tree without a writeable (\"writeable_target_test_prefix_)\") or read-only (\"PLPLOT::\") prefix should be discovered by this test (N.B. unless the unprefixed target reference occurs in CMake logic branches that are unexecuted by the particular configuration options that are chosen which makes this test necessary but not sufficient)." OFF)
 if(USE_WRITEABLE_TARGET_TEST_PREFIX)
   set(WRITEABLE_TARGET writeable_target_test_prefix_)

Just an FYI

pkg-config includedir is broken

Florian "sp1rit" — Sun, 19 Nov 2023 14:46:30 -0000

The plplot.pc provided by the plplot-devel package on openSUSE has set includedir to include/plplot. This results in the following when running pkg-config --cflags --libs plplot: -Iinclude/plplot -lplplot. This however is wrong, as -Iinclude/plplot will have the compiler looking in <cwd>/include/plplot instead of /usr/include/plplot. Other libraries that use pkg-config properly output the absolute path for their includedirs.

x09f segfaults when compiled with -fsanitize=address

Rafael Laboissière — Thu, 16 Nov 2023 07:40:41 -0000

[For context in this issue, please see these bug reports filed in Debian: 1055228 and 1055750.]

Example x09f in Fortran is generating a segmentation fault when compiled with gfortran option -fsanitize=address. The problem is reproducible on the architectures amd64 and armhf. Here is the reproducer on an amd64 Debian system:

sudo apt install libplplot-dev plplot-examples
cp -r /usr/share/doc/plplot-examples/examples/fortran/ .
cd fortran/
/usr/bin/gfortran x09f.f90 -g -o x09f  -I/usr/include/plplot -I/usr/lib/x86_64-linux-gnu/fortran/modules/plplot -lplplotfortran  -lplfortrandemolib -fsanitize=address
./x09f -dev ps -o /dev/null

The last command produces the following error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f5f81821772 in ???
#1  0x7f5f81820905 in ???
#2  0x7f5f8157b50f in ???
    at ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
#3  0x7f5f7fb010ec in ???
Segmentation fault

Here is the backtrace in GDB:

$ gdb x09f
[snip]
(gdb) run -dev ps -o /dev/null
Starting program: /var/tmp/fortran/x09f -dev ps -o /dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff58010ec in ?? ()
(gdb) bt
#0  0x00007ffff58010ec in ?? ()
#1  0x00007ffff7f22ee0 in plplot_double_private_pltransformf2c_data () from /lib/x86_64-linux-gnu/libplplotfortran.so.0
#2  0x00007ffff71c46fc in ?? () from /lib/x86_64-linux-gnu/libplplot.so.17
#3  0x00007ffff71c5881 in plfcont () from /lib/x86_64-linux-gnu/libplplot.so.17
#4  0x00007ffff71c5c69 in c_plcont () from /lib/x86_64-linux-gnu/libplplot.so.17
#5  0x00007ffff7f38964 in __plplot_double_MOD_plcont_impl_data () from /lib/x86_64-linux-gnu/libplplotfortran.so.0
#6  0x000055555555cad4 in x09f () at x09f.f90:129
#7  0x0000555555564336 in main (argc=5, argv=0x7fffffffe2e7) at x09f.f90:35
#8  0x00007ffff72456ca in __libc_start_call_main (main=main@entry=0x5555555642fd <main>, argc=argc@entry=5, argv=argv@entry=0x7fffffffde38) at ../sysdeps/nptl/libc_start_call_main.h:58
#9  0x00007ffff7245785 in __libc_start_main_impl (main=0x5555555642fd <main>, argc=5, argv=0x7fffffffde38, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde28)
    at ../csu/libc-start.c:360
#10 0x0000555555556331 in _start ()

Feature request: getter for current colour

AstroFloyd — Fri, 04 Aug 2023 09:50:52 -0000

I would like a function/subroutine that tells my program which colour (map and index) is currently being used. This information is available in the source code as plsc->curcmap and plsc->icol0, but is unavailable to my Fortran user program. This function would be the opposite of plcol0()/plcol1(). I could imagine a Fortran subroutine plgcurcol(cmap, icol), where cmap and icol are the return values containing the current colour map and index.

The use of such a procedure is when writing a function/subroutine of my own that does some plotting using PLplot. My current example is a routine that draws a graph using both solid features (alpha=1) bars and semitransparent features. The alpha value needs to be changed inside the routine, and changed back to the original before returning, as not to mess up the PLplot settings after the routine returns. Part of that Fortran routine would look like

  ! Do some plotting in default transparency...

  call plgcurcol(cmap,icol)
  if(cmap.eq.0) then
    call plgcol0a(icol, red0,green0,blue0, alpha0)   ! Store original colour
    call plscol0a(icol, red0,green0,blue0, myalpha)  ! Set desired colour
  else 
    call plgcol1a(icol, red0,green0,blue0, alpha0)   ! Store original colour
    call plscol1a(icol, red0,green0,blue0, myalpha)  ! Set desired colour
  end if

  ! Do some plotting in my desired, temporary transparency...

  if(cmap.eq.0) then
    call plscol0a(icol, red0,green0,blue0, alpha0)  ! Restore original colour
  else 
    call plscol1a(icol, red0,green0,blue0, alpha0)  ! Restore original colour
  end if

To achieve a similar goal in different circumstances, I could imagine a routine plgcurrgba(r,g,b, a) to obtain the RGB colours and alpha channel instead of the colour map and index. However, I suppose one would still need a colour map and index to assign the modified colour to, and hence plgcurcol() to get the original map/index settings and later restore them.

PS, this is low priority, but I'm not sure whether that's 1 or 9...

Crash when using PLPlot in MacOS Bundle

Jeremy Nesbitt — Thu, 08 Dec 2022 00:17:49 -0000

I am working on a Fortran application that uses PLPlot to graph data on MacOS. If I run the application from the terminal, everything works fine. But when I create a MacOS bundle, the application crashes every time during the first call to plbox with a null pointer error (see crash log below).

After some debugging, it seemslike the issue is that the call to register the cairo context is failing:
call pl_cmd(PLESC_DEVINIT, cairo_context).

If I remove this line from the application, it fails the same way whether I run it in terminal or as a MacOS bundle.

As I understand the documentation, I need to make this call to get the "extcairo" driver to work, but I cannot find a way around this issue if I want to distribute an application as a MacOS bundle that uses PLPlot. Any suggestions to deal with this would be appreciated.

Crash Log
Process: ZOA [9389]
Path: /Users/USER/Library/Mobile Documents/com~apple~CloudDocs/*/ZOA
Identifier: ZOA
Version: ???
Code Type: ARM-64 (Native)
Parent Process: zsh [611]
Responsible: Terminal [510]
User ID: 502

Date/Time: 2022-12-07 15:59:40.5134 -0800
OS Version: macOS 12.5.1 (21G83)
Report Version: 12
Anonymous UUID: 64AC6177-EDD0-B543-05D4-32CEDE8BFCA6

Sleep/Wake UUID: 34BCD013-C8A1-4B12-A855-FBE312FF5D5E

Time Awake Since Boot: 1000000 seconds
Time Since Wake: 1157 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000004
Exception Codes: 0x0000000000000001, 0x0000000000000004
Exception Note: EXC_CORPSE_NOTIFY

VM Region Info: 0x4 is not in any region. Bytes before following region: 105553518919676
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
MALLOC_NANO (reserved) 600018000000-600020000000 [128.0M] rw-/rwx SM=NUL ...(unallocated)

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libcairo.2.dylib 0x10eaed3d0 cairo_set_source_rgba + 12
1 cairo.so 0x11565f468 set_current_context + 104
2 cairo.so 0x11565f468 set_current_context + 104
3 cairo.so 0x11565f348 plD_line_cairo + 52
4 libplplot.17.0.0.dylib 0x10ee0ae00 grline + 108
5 libplplot.17.0.0.dylib 0x10ee0ad88 plP_line + 316
6 libplplot.17.0.0.dylib 0x10ee2487c genlin + 72
7 libplplot.17.0.0.dylib 0x10ee240ec plP_pllclp + 1084
8 libplplot.17.0.0.dylib 0x10ee23b9c pllclp + 88
9 libplplot.17.0.0.dylib 0x10ee23144 plP_draphy + 108
10 libplplot.17.0.0.dylib 0x10edfe028 c_plaxes + 2940
11 libplplot.17.0.0.dylib 0x10edfd4a0 c_plbox + 72
12 libplplotfortran.0.2.0.dylib 0x10ed86174 __plplot_double_MOD_plbox_impl + 372
13 ZOA 0x104b53ca0 __handlers_MOD_plot1 + 1888 (zzhandlers.f90:558)

Line that triggered the crash:
call plbox('bclnst', 0.0_plflt, 0, 'bnstv', 0.0_plflt, 0)

Thanks!

fixed-size arrays of size PL_MAXPOLY cause out-of-bound and posible crashes

giloo — Fri, 03 Jun 2022 13:32:05 -0000

xscl and yscl , used by difilt(), are of size PL_MAXPOLY whereas their contents can be of any size, (see line 534 of plcore) causing invalid memory access and code corruption.
This is most visible when drawing a filled area of a shape of size > PL_MAXPOLY on the postscript driver, that triggers difilt() due to its (IMHO too complicated) coordinate conversions.

#202 Memory leaks in clear()

Dmitry — Tue, 05 Apr 2022 19:13:32 -0000

Finally, after analysis of the sources I realized that eop() should be used to go to the beginning of the buffer.
The question is closed.

Memory leaks in clear()

Dmitry — Mon, 14 Feb 2022 20:31:42 -0000

I need to redraw plots in the created subpages.
I perform clear() and repeat drawing.
The common-sense suggests that clear() should not only erase the screen, but also release the memory occupied by the related variables. But it seems that occupied memory is not released and increases with every redrawing.
Please refer to the simple code based on Example #1 in the attached file.
The version of PlPlot is 5.13
Windows
MS VS++ 16

different size of characters between hershey and fonts

giloo — Sun, 23 Jan 2022 18:44:19 -0000

see ticket 200 also.
when using the new wxwidgets driver, (not with the old) although the size of the window and of the bow is the same, the size of the hershey characters are approx 1.8 times those of the fonts.
How to reproduce:
examples/c++/x29 -drvopt "hrshsym=1,text=0" (select 7, wxwidgets) -> big hershey characters
examples/c++/x29 -drvopt "hrshsym=1,text=1" (select 7, wxwidgets) -> small fonts labelling
It seems generally admitted that plplot produces consistent plots between all drivers.
Actually the size reported by plgchr() seem wrong also.

alignment of vertical axis labels wrong for wxwidgets (new driver)

giloo — Sun, 23 Jan 2022 18:37:05 -0000

This is only when using the Hershey font: drvopt "hrshsym=1,text=0"
Easy to reproduce:
examples/c++/x29 -drvopt "hrshsym=1,text=0" (select 7, wxwidgets) -> wrong Y axis
examples/c++/x29 -drvopt "hrshsym=1,text=1" (select 7, wxwidgets) -> good Y axis