Prev: Simple hack to get $500 to your home.
Next: Functions with side effects
From: robin on 14 Jul 2010 12:41
Benjamin wrote in message <8a03092b-2b9d-4774-94ec-56c9f61e86fd(a)t10g2000yqg.googlegroups.com>...
>I have to say sorry about my poor English.
>I'm suffering a problem of segmentation fault.
>my guess is that SIGSEGV is caused by memory allocation in a loop.
>I've excluded other frequent causes (array index, arguments in the
>routine, POINTER)
>
>I explain my main code briefly...
>
>It's an iteration progress.
>Get the variable array jac by subroutine radiance_function, then pass
>to subroutine DRN2G
>IV can be evaluated by the routine DRN2G (from NETlib), then do next
>step (radiance function) with respect to the value of IV(1) again...
>
>INTEGER :: liv
>INTEGER :: IV(liv)


"liv" cannot be defined in the same procedure as IV.


From: dpb on 14 Jul 2010 13:50
robin wrote:
....

>>
>> INTEGER :: liv
>> INTEGER :: IV(liv)
>
>
> "liv" cannot be defined in the same procedure as IV.

Not necessarily so...

A line ahead of these not shown (along w/ a whole bunch else) could just
as easily be

PARAMETER (liv = 1000)

or the above two lines are also valid in a routine in which array IV is
an adjustable array.

Not nearly enough shown to ascertain anything useful...

--
From: robin on 14 Jul 2010 21:40
dpb wrote in message ...
>robin wrote:
>...
>
>>>
>>> INTEGER :: liv
>>> INTEGER :: IV(liv)
>>
>>
>> "liv" cannot be defined in the same procedure as IV.
>
>Not necessarily so...
>
>A line ahead of these not shown (along w/ a whole bunch else)

We are shown what was important.

> could just as easily be

>PARAMETER (liv = 1000)

If it were, the OP would have used INTEGER :: IV(1000)

So the answer is, no, is wasn't.


From: Benjamin on 15 Jul 2010 10:36


> Based on the "Address 0x0" in the error message, I would guess that II
> is 0 and YI has not been allocated.  Either you tried to allocate the
> array with a status argument which you ignored, or you forgot to
> allocate it.
>
> Louis

Yes, YI needs to be automatically reallocated..I solved it..thanks
Louis.

But I found another problem...
==9866== Invalid read of size 4
==9866== at 0x43D4D5: ir_spectra_limb_fit_ (in /users/xu_jn/ars4DLR/
src/forCATS/pils/pils)
==9866== by 0x4027BB: MAIN__ (in /users/xu_jn/ars4DLR/src/forCATS/
pils/pils)
==9866== by 0x4CFE6B: main (in /users/xu_jn/ars4DLR/src/forCATS/
pils/pils)
==9866== Address 0x15ced4cc is not stack'd, malloc'd or (recently)
free'd

From: dpb on 15 Jul 2010 11:10
robin wrote:
> dpb wrote in message ...
>> robin wrote:
>> ...
>>
>>>> INTEGER :: liv
>>>> INTEGER :: IV(liv)
>>>
>>> "liv" cannot be defined in the same procedure as IV.
>> Not necessarily so...
>>
>> A line ahead of these not shown (along w/ a whole bunch else)
>
> We are shown what was important.

Not _all_ of what was important (and some that wasn't) including the
above had nothing whatsoever to do w/ the actual error of this posting.

>> could just as easily be
>
>> PARAMETER (liv = 1000)
>
> If it were, the OP would have used INTEGER :: IV(1000)
>
> So the answer is, no, is wasn't.

You can't know that. You can presume it and would probably be right but
it can't be known from the information posted. What is posted _does_
have at least two ways of being correct that can't be shown to be
incorrect from the same limited information.

The point made is that there are other forms of the source shown that
are perfectly legal (including that what was the specific problem
generating the posting had nothing to do w/ either of these two variables).

Of course, as the OP's followup posting shows, he's got more of the same
issues of not cleanly ALLOCATEing than the one that Louis pointed out;
OP will just have to work thru his code paying more precise attention to
necessary detail to find/correct his problems.

--
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Simple hack to get $500 to your home.
Next: Functions with side effects