segmentation fault with gnuplotfortran

Hi all,
I am using gnuplotfortran (0.1.1), fortranposix (0.1-alpha) on
debian sid. I compiled these two packages (makefiles attached below)
using GNU make (3.80), ifort (8.1, build 20040921Z). When I am running
a sample program (attached below) I get the following errors. The
program compiles without any errors, but segfaults during execution.

I am not sure where I am going wrong (program, making the libs,
gnuplot incompatibility ...). I would be greatful if you can point me
in the right direction.


$ifort -c using_gnuplot.f90

$ifort using_gnuplot.o -L /usr/local/lib/gnuplotfortran/ -L
/usr/local/lib/fortran/ -L /usr/local/lib/fortranposix/
-lfortranposix_ifort_20040921Z -lgnuplotfortnposix/
-lfortranposix_ifort_20040921Z -lgnuplotfortran_ifort_20040921Z -o
using_gnuplot

$./using_gnuplot
gnuplot_init : current display identified as   :0.0  {4}
No checking of     -persist as a valid X option will be done ...
Executing gnuplot -persist (16) with option w (1) ...
Opened pipe for GNUPlot-Fortran95 IPC : file descriptor 4
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC        Routine            Line        Source
Unknown            4000DC47  Unknown               Unknown  Unknown
using_gnuplot      0804CFAA  Unknown               Unknown  Unknown
using_gnuplot      0804CED8  Unknown               Unknown  Unknown
Unknown            4102E7F8  Unknown               Unknown  Unknown


******** other system specific information ***********
$gnuplot

G N U P L O T
Version 4.0 patchlevel 0
last modified Thu Apr 15 14:44:22 CEST 2004
System: Linux 2.6.8-1-386

$uname -a
Linux kusumanchi 2.6.8-1-386 #1 Thu Nov 11 12:18:43 EST 2004 i686
GNU/Linux

$gcc --version
gcc.real (GCC) 3.3.4 (Debian 1:3.3.4-13)



********* sample program **********************
program using_gnuplot
use datatypes, only : i4b, dp
use gnuplot_module_data, only : gnuplot_ctrl
use gnuplot_module
implicit none

type(gnuplot_ctrl), pointer :: ptr_gctrl
real(dp) :: x(4) = (/ 1., 2., 3., 4. /), y(4) = (/1.2, 3.1, 4.2, 3.4
/)
integer :: status

ptr_gctrl=>gnuplot_init('-persist')
status = gnuplot_plot2d(ptr_gctrl, 4, x, y)
end program using_gnuplot


********* makefile for gnuplotfortran ***********
#LIBRARYFILE=libgnuplotfortran.so
 LIBRARYFILE=libgnuplotfortran_ifort_2004
0921Z.so

RM=rm -f

# Your fortran compiler
#F95C=f95
F95C=ifort
# Option for generating shared libraries on your Fortran compiler
F95SHAREDOPTION=-shared

compf95=$(F95C) $(F95SHAREDOPTION) $(@F:.so=.f90)

all: $(LIBRARYFILE)

clean :
$(RM) *.o

$(LIBRARYFILE) ::
$(F95C) $(F95SHAREDOPTION) gnuplot_fortran95.f90 -o $(LIBRARYFILE)


************ makefile for fortranposix **************
 LIBRARYFILE=libfortranposix_ifort_200409
21Z.so

RM=rm -f

# Your fortran compiler
F95C=ifort
# Option for generating shared libraries on your Fortran compiler
F95SHAREDOPTION=-shared
# Your C compiler
CC=gcc

compf95=$(F95C) $(F95SHAREDOPTION) $(@F:.so=.f90)
compc=$(CC) -c $(@F:.o=.c)

OBJFILES=posixwrapper.o

all: $(LIBRARYFILE) clean

clean :
$(RM) *.o

$(LIBRARYFILE) :: $(OBJFILES)
$(F95C) $(F95SHAREDOPTION) fortranposix.f90 -o $(LIBRARYFILE)
$(OBJFILES)

posixwrapper.o : posixwrapper.c
$(compc)



thanks
raju

"Kamaraju Kusumanchi"  wrote

The  program compiles without any errors, but segfaults during execution.
>

I was hoping to read a more expert response, but seeing none, I will toss in
my bit.  I have no idea what the message "segmentation violation" really
means, but usually I have omitted an EXTERNAL declaration or made a gross
blunder in the arguments to a subroutine.

Charles Russell wrote:
> "Kamaraju Kusumanchi"  wrote
>
> The  program compiles without any errors, but segfaults during execution.
>
>
> I was hoping to read a more expert response, but seeing none, I will toss 
in
> my bit.  I have no idea what the message "segmentation violation" really
> means, but usually I have omitted an EXTERNAL declaration or made a gross
> blunder in the arguments to a subroutine.
>
>
I am not sure. The program runs fine, If I am using ifc Version 7.1
Build 20040309Z. The problem arises only with ifort (8.1, build
20040921Z). So I doubt if I made a mistake in passing arguments to the
subroutines. Anyway, I will check it up and see if there is anything
fishy going on.

thanks
raju

Kamaraju Kusumanchi wrote:

> Charles Russell wrote: 
> I am not sure. The program runs fine, If I am using ifc Version 7.1
> Build 20040309Z. The problem arises only with ifort (8.1, build
> 20040921Z). So I doubt if I made a mistake in passing arguments to the
> subroutines. Anyway, I will check it up and see if there is anything
> fishy going on.
>
> thanks
> raju


There were bugs in the code (somehow compiled and ran correctly on Sun and
older version of IFC, but not the new one). These have been fixed. See my
other post.

"Charles Russell" <STOPworworSPAM@bellsouth.net> writes:

> I have no idea what the message "segmentation violation" really
> means,

What it really means turns out to be pretty crypic and unhelpful.
It mostly means that something tried to reference an invalid
memory address.  (The "segmentation" part probably relates to
memory segments).

> but usually I have omitted an EXTERNAL declaration or made a gross
> blunder in the arguments to a subroutine.

Lists of likely causes turn out to be a lot more useful here than the
actual meaning of "segmentation violation".  Turns out that there are
*MANY* things that can show up as a segmentation violation.  Exceeding
array bounds is probably the most "obvious" as you can directly see how
it might relate to invalid memory addresses.  But things like messing
up subroutine arguments can cause data that isn't supposed to be a
memory address to get misinterpreted as one; it is probably a more
common reason than the "obvious" array bounds one.  And there are
many others.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

>(The "segmentation" part probably relates to memory segments).

I believe it relies on particulars of the way Unix on the PDP-11
archictected virtual memory. There also was (and perhaps still is)
"bus error", which means you referenced an address on the Unibus,
the PDP-11's I/O bus that was invalid - which usually has one of
the same reasons as a "segmentation violation".

Or, as John Mashey would put it, it's a first implementation artifact
shining through decades later.

Jan

Jan Vorbrüggen wrote:
 

> I believe it relies on particulars of the way Unix on the PDP-11
> archictected virtual memory. There also was (and perhaps still is)
> "bus error", which means you referenced an address on the Unibus,
> the PDP-11's I/O bus that was invalid - which usually has one of
> the same reasons as a "segmentation violation".

> Or, as John Mashey would put it, it's a first implementation artifact
> shining through decades later.

More or less, you referenced memory you shouldn't have,
and you referenced memory that doesn't even exist.  It
doesn't really make much difference to the user, and on
many machine/OS combinations it doesn't make much difference
at all.

-- glen

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:

> There also was (and perhaps still is)
> "bus error", which means you referenced an address on the Unibus,
> the PDP-11's I/O bus that was invalid - which usually has one of
> the same reasons as a "segmentation violation".

Yes, there are still bus errors, and there is a lot of overlap in
the Fortran errors that cause it.  As far as I can see, and sloppily
speaking...

Segmentation violation tends to be an error in the high order bits of
the address.  You tried to address memory out of the range of memory
accessible to you.

Bus error tends to be an error in the low few bits.  You tried to do
something like address something that was misaligned, such as accessing
a 32-bit "word" that isn't aligned on a word (or even nibble) boundary.
The memory is in range, but the hardware can't do that particular
operation with that alignment.

Of course, if you are getting garbage interpreted as a memory address,
either of these symptoms could occur.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain