Re: segmentation fault on calloc

From: nobody (nobody_at_nowhere.non)
Date: 11/02/03 

Date: Sun, 02 Nov 2003 21:47:36 GMT

"Mathieu Fregeau" <mathieu.fregeau@polymtl.ca> wrote in message
news:Zkdpb.730$mB5.98677@news20.bellglobal.com...
> Hi Mans,
>
> in fact, there is documentation, but not intended to an eventual
developper
> to modify its source... only for a user! The long reply list suggest me
that
> nobody in the world have an idea of a solution. am I right?
>
    No, you are not right, Not even I have slightest idea :-)
On serious note, there is commented-out code in fvcalc(). Did the program
SIGSEGV with this code excluded? There is also commented-out call to
_heapmin(), which in the context of problem you are describing looks
suspicious (I'm guessing just by name, bo idea what this func does).
    As others said, there are situations where you can't find cause of the
problem only from a part of code, without actually setting behind terminal
and running/debugging it.
    One possibility no one had mentioned (and I'm again guessing) - are you
calling C code from FORTRAN code properly? I would say that there
could be different mechanisms for argument passing, and if you are doing
something wrong, stack can be corrupted and .. I was thinking along the
lines that SIGSEGV maybe happens when assigning result of calloc() call to
variable. I know it's a wild guess, but without entire code, same
environment
as you have and debugger (to step through assembly code) there is not really
much anyone can do. BTW, you've mentioned that you are not very familiar
with debuggers on AIX, so question is, how do you know it was SEGV and
on indicated line? They have pretty good (GUI) debugger on AIX called
xldb. Maybe you will be more comfortable with it than dbx.
    But as others said, most likely it could be corrupted heap.

> Mathieu
> "Måns Rullgård" <mru@kth.se> a écrit dans le message de
> news:yw1xn0ber5py.fsf@kth.se...
> > "Mathieu Fregeau" <mathieu.fregeau@polymtl.ca> writes:
> >
> > >> > code. Rewritting the code is NOT an option. (about 10 years of
> > >> > developement at NASA).
> > >>
> > >> Unfortunately there are many cases where a decade of development has
> > >> produced an astonishing amount terrible code. It might be working,
> > >> but any attempt to tinker with it results in things breaking, as we
> > >> have seen. If only people could structure their code a little bit.
> > >
> > > in fact it is structured, but it is not documented.
> >
> > OK for structured, but it uses global variables, which is bad. As for
> > documentation, that's equally important to code quality when dealing
> > with long-lived code. I can barely understand my own code that I
> > wrote less than a year ago.
> >
> > --
> > Måns Rullgård
> > mru@kth.se
>
>