segmentation fault caused by allocate memory in a loop?
in [Fortran]
|
From: Benjamin on 14 Jul 2010 03:56 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) DO WHILE (.true.) ... CALL DRN2G (jac, target....IV...) if (IV(1) < 2) THEN CALL radiance_function (jac, target..) ... END DO SUBROUTINE radiance_function(jac. target..) INTEGER, INTENT(INOUT) :: n REAL, INTENT(OUT) :: jac INTEGER, INTENT(IN) :: target .... ! intermediate quantities, computed at first time or iteration DOUBLE PRECISION, ALLOCATABLE, SAVE :: grid(:) DOUBLE PRECISION, ALLOCATABLE, SAVE :: transmission(:) DOUBLE PRECISION, ALLOCATABLE, SAVE :: radiance(:) IF (n = 1) THEN ALLOCATE(grid(0:a), STAT=...) ALLOCATE(transmission(0:b), STAT=...) ALLOCATE(radiance(0:c), STAT=...) print *, "" END IF grid = transmission = radiance = .... .... jac = values of these intermediate quantities (grid, transmission, radiance) should stay same in iteration. And jac is calculated by these quantities and different target values. Sorry about this general description, my questions is that if I do have to move this allocation progress outside of the routine. can I avoid SIGSEGV by DEALLOCATE statement at the end of this routine? Will this action affect the values of intermediate quantities?
From: Richard Maine on 14 Jul 2010 04:29 Benjamin <benjaminxj(a)googlemail.com> wrote: > 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... Your English is fine. But... Pretty much the number 1 piece of advice for anyone asking for debugging help is to not try to describe your guesses about what the problem is, but rather to show the raw data, preferably in the form of exact code that can duplicate the problem, along with the exact error messages or other symptoms. When someone asking for help says that they have eliminated various possibilities, it very often means that the possibilities that they thought they eliminated are where the problem lies, and that theit difficulty in finding it is because they are now looking in the wrong places - the same places they are suggesting that others might look. That's not always the case, but it is so often enough that my immediate reaction when someone says they have eliminated some possibility is to question that. You haven't given enough data for much diagnosis. About the only "easy" idea I can suggest is that you might be trying to allocate more memory than is available. Allocatables are not as prone to that as automatics, which quite often exceed smell default stack limits, however. Most of the other likely possibilities for segmentation faults relate to the things you claim to have eliminated - array bounds errors, argument mismatches, and pointer errors. You have presented no data that suggest to me any reason to suspect that deallocating and reallocating would help anything. If you actually have any such data, I don't see it. Seems to me like more of a random shot in the dark. In fact, I don't see any data that shows that the problem is even anywhere close to the code snippet you showed. An unsupported guess doesn't count as data. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: nmm1 on 14 Jul 2010 05:02 In article <1jllhu7.b5p00x1ff0w4qN%nospam(a)see.signature>, Richard Maine <nospam(a)see.signature> wrote: > >Most of the other likely possibilities for segmentation faults relate to >the things you claim to have eliminated - array bounds errors, argument >mismatches, and pointer errors. Not entirely. Misunderstanding the specification and doing something syntactically or semantically invalid (but plausible) is also quite common, as soon as you do anything complicated. Fortran has MUCH less of that than C++ (where I have just been going bananas with such problems), because far more of such errors get diagnosed, but there are quite a few ways in which it happens. I didn't see any of the usual culprits in the code, however. Regards, Nick Maclaren.
From: Benjamin on 14 Jul 2010 05:51 On 14 Jul., 10:29, nos...(a)see.signature (Richard Maine) wrote: > You have presented no data that suggest to me any reason to suspect that > deallocating and reallocating would help anything. If you actually have > any such data, I don't see it. Seems to me like more of a random shot in > the dark. In fact, I don't see any data that shows that the problem is > even anywhere close to the code snippet you showed. An unsupported guess > doesn't count as data. Richard, thanks for your suggestion. I used valgrind to debug the code...I got this message. ==25776== Invalid write of size 8 ==25776== at 0x4961FA: uvip3p_dd_ (akima.f:567) ==25776== by 0x4367D9: __limb_ir_model_MOD_limb_ir_radiance_function (in /users/xu_jn/ars4DLR/ src/forCATS/pils/pils) ==25776== by 0x4416D3: pils_n2g_ (in /users/xu_jn/ars4DLR/src/ forCATS/pils/pils) ==25776== by 0x440164: port_pils_driver_ir_ (in /users/xu_jn/ ars4DLR/src/forCATS/pils/pils) ==25776== by 0x43CCFD: ir_spectra_limb_fit_ (in /users/xu_jn/ ars4DLR/src/forCATS/pils/pils) ==25776== by 0x4027BB: MAIN__ (in /users/xu_jn/ars4DLR/src/forCATS/ pils/pils) ==25776== by 0x4CFA5B: main (in /users/xu_jn/ars4DLR/src/forCATS/ pils/pils) ==25776== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==25776== ==25776== Process terminating with default action of signal 11 (SIGSEGV) ==25776== Access not within mapped region at address 0x0 ==25776== at 0x4961FA: uvip3p_dd_ (akima.f:567) ==25776== by 0x4367D9: __limb_ir_model_MOD_limb_ir_radiance_function (in /users/xu_jn/ars4DLR/ src/forCATS/pils/pils) ==25776== by 0x4416D3: pils_n2g_ (in /users/xu_jn/ars4DLR/src/ forCATS/pils/pils) ==25776== by 0x440164: port_pils_driver_ir_ (in /users/xu_jn/ ars4DLR/src/forCATS/pils/pils) ==25776== by 0x43CCFD: ir_spectra_limb_fit_ (in /users/xu_jn/ ars4DLR/src/forCATS/pils/pils) ==25776== by 0x4027BB: MAIN__ (in /users/xu_jn/ars4DLR/src/forCATS/ pils/pils) ==25776== by 0x4CFA5B: main (in /users/xu_jn/ars4DLR/src/forCATS/ pils/pils) It seems like that the error is generated at line 567 of routine uvip3p_dd in akima.f. The line 567 is that ! Evaluates the YI value. YI(II)=Y0+(A1*(XII-X0)) YI is one of the local variable (dynamic array which I allocate memory before the loop) in routine limb_ir_radiance_function, which is calculated by routine uvip3p_dd in a loop.
From: Louis Krupp on 14 Jul 2010 07:24 On 7/14/2010 3:51 AM, Benjamin wrote: > On 14 Jul., 10:29, nos...(a)see.signature (Richard Maine) wrote: > >> You have presented no data that suggest to me any reason to suspect that >> deallocating and reallocating would help anything. If you actually have >> any such data, I don't see it. Seems to me like more of a random shot in >> the dark. In fact, I don't see any data that shows that the problem is >> even anywhere close to the code snippet you showed. An unsupported guess >> doesn't count as data. > > Richard, thanks for your suggestion. > I used valgrind to debug the code...I got this message. > > ==25776== Invalid write of size 8 > ==25776== at 0x4961FA: uvip3p_dd_ (akima.f:567) > ==25776== by 0x4367D9: > __limb_ir_model_MOD_limb_ir_radiance_function (in /users/xu_jn/ars4DLR/ > src/forCATS/pils/pils) > ==25776== by 0x4416D3: pils_n2g_ (in /users/xu_jn/ars4DLR/src/ > forCATS/pils/pils) > ==25776== by 0x440164: port_pils_driver_ir_ (in /users/xu_jn/ > ars4DLR/src/forCATS/pils/pils) > ==25776== by 0x43CCFD: ir_spectra_limb_fit_ (in /users/xu_jn/ > ars4DLR/src/forCATS/pils/pils) > ==25776== by 0x4027BB: MAIN__ (in /users/xu_jn/ars4DLR/src/forCATS/ > pils/pils) > ==25776== by 0x4CFA5B: main (in /users/xu_jn/ars4DLR/src/forCATS/ > pils/pils) > ==25776== Address 0x0 is not stack'd, malloc'd or (recently) free'd > ==25776== > ==25776== Process terminating with default action of signal 11 > (SIGSEGV) > ==25776== Access not within mapped region at address 0x0 > ==25776== at 0x4961FA: uvip3p_dd_ (akima.f:567) > ==25776== by 0x4367D9: > __limb_ir_model_MOD_limb_ir_radiance_function (in /users/xu_jn/ars4DLR/ > src/forCATS/pils/pils) > ==25776== by 0x4416D3: pils_n2g_ (in /users/xu_jn/ars4DLR/src/ > forCATS/pils/pils) > ==25776== by 0x440164: port_pils_driver_ir_ (in /users/xu_jn/ > ars4DLR/src/forCATS/pils/pils) > ==25776== by 0x43CCFD: ir_spectra_limb_fit_ (in /users/xu_jn/ > ars4DLR/src/forCATS/pils/pils) > ==25776== by 0x4027BB: MAIN__ (in /users/xu_jn/ars4DLR/src/forCATS/ > pils/pils) > ==25776== by 0x4CFA5B: main (in /users/xu_jn/ars4DLR/src/forCATS/ > pils/pils) > > It seems like that the error is generated at line 567 of routine > uvip3p_dd in akima.f. The line 567 is that > ! Evaluates the YI value. > YI(II)=Y0+(A1*(XII-X0)) > > YI is one of the local variable (dynamic array which I allocate memory > before the loop) in routine limb_ir_radiance_function, which is > calculated by routine uvip3p_dd in a loop. > > > 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
|
Next
|
Last
Pages: 1 2 3 Prev: Simple hack to get $500 to your home. Next: Functions with side effects |