Unwanted breakpoint in NTDLL

[Intel_C_Intel]

In one of my programs, when I run it in debug mode it always breaks at an Int 3 line in NTDLL that I did not (could not) set. I read at another site that this is evidently hard-coded debug breakpoint that Microsoft forgot to take out. I could just hit "continue" and be on my merry way but the problem is it's happening inside a loop that can cycle literally thousands of times. Does anyone know a work-around for this?

In case I wasn't clear, the break point is not in my source code. I've tried hitting "clear all breakpoints" but this does not work.

Thanks,

Randy

[Steven_L_Intel1]

I don't believe the hard-coded breakpoint story. Rather, something is signalling an exception. Does it always happen at the same place in your program? Can you step through the code and find the statement that causes the problem?

Steve

[Jugoslav_Dujic]

These breakpoints (user breakpoint called from XXXXX) aren't well documented, but from my experience they denote some subtle programming errors by you.
Typically, they occur when you pass an insufficient buffer, invalid pointer and similar to a library function. Usually, these let you go by but indicate that something is fishy. My suggestion is that you check where they originate from (click "Call stack" button on debug toolbar and select your last routine), and then carefully check arguments. A typical sample is something like (off the top of my head, so I may be wrong for the particular case):

CHARACTER(4) sBuf 
READ(sBuf, *) iFoo

-- list-directed format is used on a too small buffer.

Jugoslav

[Intel_C_Intel]

Here's the offending code. Jugoslav, I tried opening the "call stack" window but got the following error:

Call Stack: MSDEV.EXE - Application Error
The instruction at "0x52607e48" referenced memory at "0x00000000". The memory could not be "written".

But anyway, I'm pretty sure the problem is somewhere in here, because if I set a breakpoint on line 6 it executes fine up to that point. Further more, if I continue stepping through the assembly code it finally ends up at line 31. So it looks like your guess is on track because evidently line 30 is the offender but I don't see what's wrong with it. Here's the really weird thing, lines 6 and 7 are inside of a loop. If I set the breakpoint right after line 7 and hit "go" sometimes it cycles throught fine and sometimes it goes off to assembly land. Any ideas?

************************************ Code snippet ******************************************
1 CHARACTER STRING*80
2 INTEGER JTEMP(5)
3 .
4 .
5 .
6 READ(10,'(A)')STRING
7 CALL PARSE_INTS(STRING,JTEMP)
8 .
9 .
10 .
11 SUBROUTINE PARSE_INTS(STRING, IA)
12 *
13 * Input: STRING - string consisting of up to five integers with comma, tab, or space delimiters.
14 * Returns: IA - array with integers from STRING parsed out
15 *
16 CHARACTER*(*) STRING
17 INTEGER IA(5), BEG
18
19 I = 0
20 IA=0 ! Zero IA (Integer Array)
21 BEG = 1
22 IOS = 0
23 LENGTH = LEN(STRING)
24 DO WHILE(IOS .EQ. 0 .AND. I .LT. 5)
25 I=I+1
26 DO WHILE(STRING(BEG:BEG) .EQ. ' ' .OR. STRING(BEG:BEG) .EQ. CHAR(9) .OR. STRING(BEG:BEG) .EQ. ',') ! CHAR(9) = TAB
27 BEG = BEG + 1
28 IF(BEG .GT. LENGTH)RETURN
29 END DO
30 READ(STRING(BEG:),*,IOSTAT=IOS)IA(I)
31 DO WHILE(STRING(BEG:BEG) .NE. ' ' .AND. STRING(BEG:BEG) .NE. CHAR(9) .AND. STRING(BEG:BEG) .NE. ',' .AND. I .LT. 5)
32 BEG = BEG + 1
33 IF(BEG .GT. LENGTH)RETURN
34 END DO
35 END DO
36 RETURN
37 END
************************************* End of Code snippet *****************************************

[Intel_C_Intel]

Let me try again, something happened to the at the end of each line of code.

Here's the offending code. Jugoslav, I tried opening the "call stack" window but got the following error:

Call Stack: MSDEV.EXE - Application Error
The instruction at "0x52607e48" referenced memory at "0x00000000". The memory could not be "written".

But anyway, I'm pretty sure the problem is somewhere in here, because if I set a breakpoint on line 6 it executes fine up to that point. Further more, if I continue stepping through the assembly code it finally ends up at line 31. So it looks like your guess is on track because evidently line 30 is the offender but I don't see what's wrong with it. Here's the really weird thing, lines 6 and 7 are inside of a loop. If I set the breakpoint right after line 7 and hit "go" sometimes it cycles throught fine and sometimes it goes off to assembly land. Any ideas?

Code snippet 1       CHARACTER STRING*80 
2       INTEGER JTEMP(5) 
3       . 
4       . 
5       . 
6       READ(10,'(A)')STRING 
7   	CALL PARSE_INTS(STRING,JTEMP) 
8   	. 
9   	. 
10  	. 
11  	SUBROUTINE PARSE_INTS(STRING, IA) 
12  * 
13  * Input: STRING - string consisting of up to five integers with comma, tab, or space delimiters. 
14  * Returns: IA - array with integers from STRING parsed out 
15  * 
16  	CHARACTER*(*) STRING 
17  	INTEGER IA(5), BEG 
18   
19  	I = 0 
20  	IA=0	! Zero IA (Integer Array) 
21  	BEG = 1 
22  	IOS = 0 
23  	LENGTH = LEN(STRING) 
24  	DO WHILE(IOS .EQ. 0 .AND. I .LT. 5) 
25  		I=I+1 
26  		DO WHILE(STRING(BEG:BEG) .EQ. ' ' .OR. STRING(BEG:BEG) .EQ. CHAR(9) .OR. STRING(BEG:BEG) .EQ. ',') ! CHAR(9) = TAB 
27  			BEG = BEG + 1 
28  			IF(BEG .GT. LENGTH)RETURN 
29  		END DO 
30  		READ(STRING(BEG:),*,IOSTAT=IOS)IA(I) 
31  		DO WHILE(STRING(BEG:BEG) .NE. ' ' .AND. STRING(BEG:BEG) .NE. CHAR(9) .AND. STRING(BEG:BEG) .NE. ',' .AND. I .LT. 5) 
32  			BEG = BEG + 1 
33  			IF(BEG .GT. LENGTH)RETURN 
34  		END DO 
35  	END DO 
36  	RETURN 
37  	END 

[Steven_L_Intel1]

You have an access violation - your code is writing to an address that is invalid. Since you have 5.0, and not 6.x, I suggest you do this. Start the program in the debugger (set a breakpoint at the beginning of the program). Select Debug..Exceptions. Find the entry for access violation, select it, change action to Stop Always. Click OK. Continue executing. The debugger will then stop at the point of the error.

You may want to see my article on access violations in Visual Fortran Newsletter 7

Steve

[Intel_C_Intel]

Steve,

I tried your suggestion but it just did the same thing.
The message was:
User breakpoint called from code at 0x77f7629c

The context in the local window is NTDLL.

I'm still stumped.

[Steven_L_Intel1]

Sorry, I'm out of ideas. If you were running a current version, I could help you more.

Steve

[Jugoslav_Dujic]

I tried your code on my 5.0D and it worked fine but for several combinations of STRING hard-coded by me. I couldn't figure out what the value should be to produce Access violation. Try:

- Check Project/Settings/Fortran/Run time/Array & string bounds check box

- Hint: you can still switch from "Assembly view" to "Code view" just using ctrl+Tab.

- Have you upgraded to 5.0D (still can be found here)? Release notes for 5.0D mention only " - A bug which prevented a list-directed read to continue where a
non-advancing formatted read had left off was fixed.
". Looks related though by no means identical.

- MSDEV's crash is a PITA indeed. I suggest you add a test WRITE your just read string to another file (i.e. make a copy of the original file line-by-line). In this way, you'll find out which string caused the problem. (The last copied).

HTH

Jugoslav