For Programmers: Free Programming Magazines  


Home > Archive > Fortran > November 2004 > segmentation fault with gnuplotfortran









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author segmentation fault with gnuplotfortran
Kamaraju Kusumanchi

2004-11-19, 3:58 pm

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
Charles Russell

2004-11-20, 3:56 pm


"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.


Kamaraju Kusumanchi

2004-11-21, 3:58 am

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
Madhusudan Singh

2004-11-21, 8:56 am

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.
Richard E Maine

2004-11-22, 3:58 pm

"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
Jan Vorbrüggen

2004-11-23, 8:57 am

>(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
glen herrmannsfeldt

2004-11-23, 8:57 am

Jan Vorbrüggen wrote:

[color=darkred]
> 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

Richard E Maine

2004-11-23, 3:58 pm

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
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com