Prev: Simple hack to get $500 to your home.
Next: Functions with side effects
From: dpb on 15 Jul 2010 11:15
Benjamin wrote:
>
>> 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

Looks again like you're missing a set of paths to get clean
ALLOCATE/DEALLOCATE pairings.

You need to start and work through the code systematically and trace
that every array is ALLOCATEd _before_ being used and the DEALLOCATEd
before trying to ALLOCATE it again.

Also, as noted earlier, either be certain to test every return status
variable or remove them so the runtime will abort at that point rather
than silently continuing until a problem is found at a later, removed
location thereby masking the real problem.

--
From: Louis Krupp on 15 Jul 2010 12:30
On 7/15/2010 8:36 AM, Benjamin wrote:
>
>
>> 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
>

You are about to become very familiar with your interactive debugger (I
use gdb).

Make sure everything is compiled with the -g flag. I noticed that
valgrind didn't report a source file and line number for this last
error; could you have compiled something without -g?

If your program crashes when you run it with the debugger, you'll be
well on your way to figuring this out. If it doesn't, you should be
able to set a breakpoint at the code address reported by valgrind
(0x43D4D5) and see what you're doing at that point.

Louis

From: robin on 15 Jul 2010 21:37
dpb wrote in message ...
>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.

My response was based on the information provided,
and that response was correct.


From: Benjamin on 16 Jul 2010 04:24
On 15 Jul., 18:30, Louis Krupp <lkrupp_nos...(a)indra.com.invalid>
wrote:
> On 7/15/2010 8:36 AM, Benjamin wrote:
>
>
>
>
>
> >> 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

>
> Make sure everything is compiled with the -g flag.  I noticed that
> valgrind didn't report a source file and line number for this last
> error;  could you have compiled something without -g?
>
> If your program crashes when you run it with the debugger, you'll be
> well on your way to figuring this out.  If it doesn't, you should be
> able to set a breakpoint at the code address reported by valgrind
> (0x43D4D5) and see what you're doing at that point.
>
> Louis

thanks, Louis...I did compiled with -g..but I don't know why valgrind
tells me only the address without line number...
By the way, what does 0x43D4D5 exactly mean?
From: Louis Krupp on 16 Jul 2010 12:52
On 7/16/2010 2:24 AM, Benjamin wrote:
> On 15 Jul., 18:30, Louis Krupp<lkrupp_nos...(a)indra.com.invalid>
> wrote:
>> On 7/15/2010 8:36 AM, Benjamin wrote:
>>
>>
>>
>>
>>
>>>> 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
>
>>
>> Make sure everything is compiled with the -g flag. I noticed that
>> valgrind didn't report a source file and line number for this last
>> error; could you have compiled something without -g?
>>
>> If your program crashes when you run it with the debugger, you'll be
>> well on your way to figuring this out. If it doesn't, you should be
>> able to set a breakpoint at the code address reported by valgrind
>> (0x43D4D5) and see what you're doing at that point.
>>
>> Louis
>
> thanks, Louis...I did compiled with -g..but I don't know why valgrind
> tells me only the address without line number...
> By the way, what does 0x43D4D5 exactly mean?

It's the IP (instruction pointer) address. Once compiled and linked,
your program is in machine language, a stream of instructions that your
CPU (central processing unit) understands. Each instruction has a
virtual memory address. The CPU keeps the address of the next
instruction to execute in a register (if the CPU were a program, the
register would be one of its variables) call the instruction pointer.

Your debugger should let you set a breakpoint at a particular IP.

Since valgrind didn't report a line number, it is possible that the
problem is showing up in code that you didn't write but which the
compiler generated for you. Your debugger will show you machine
language instructions as if they were in assembly language (look this up
if you need to), and you may have to find someone who can read this.

Make sure you're compiling with options that check array bounds; this
might show where things are going wrong.

Louis

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