Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29285 Discussions

User breakpoint called from code at .......

Deleted_U_Intel
Employee
574 Views
I have a new problem. I'm trying to make a parser program. When i run it alone (exe file) works fine, but when i used it in a big project told me "User breakpoint called from code at 0x77f65a58". This is not an error, but the program crash. What do you know about this message?.
With CVF 6.5 don't happend, but with 6.6 yes.
0 Kudos
2 Replies
Jugoslav_Dujic
Valued Contributor II
574 Views
I've seen this on verysimilar situations (but, alas,I can't recall exact circumstances).
What's the LEN(CADEXP)? Where does the value "1" of CADEXP come from? I have a hunch that there's more than plain "1" in there. If it's a C-style string (char(0)) terminated, what you see in the debugger is not what you get -- there are possibly garbage charactersafter the terminating char(0) which cause the READ statement to fail. To see what's really in there, open "Memory" debugger window, and type "cadexp" in there. If I'm right, before the crash there will be something like:
31 00 CD CD CD ... (CD's may be something else)
whileREAD expects
31 20 20 20 20 ... ("1" followed by spaces)
in any case, you should probably add IOSTAT=iErr specifier into READ statement and test for the success (iErr=0).
(If I recall correctly, earlier compilers did have problems with statements like READ(string,*) when LEN(string) issmaller than the default list-directed format width, but I'm pretty sure it's fixed in the meantime)
Jugoslav

Message Edited by JugoslavDujic on 10-18-2004 09:54 AM

0 Kudos
Jugoslav_Dujic
Valued Contributor II
574 Views
The two lines (assignment and READ) are not the culpritthemselves -- there's something else fishy going on between the two. How many lines are there between them? If not too many, you can go step by step in debugger and watch the memory window -- I bet some other line will cause the overwrite over value of CADEXP.
In particular, I'm suspicious about declaration:
SUBROUTINE MONOMIOS(CADENA,FF)
USE ESTRUCT
CHARACTER*ILONG CADENA
If the actual string argument matching CADENA is shorter than ILONG characters, you can easily have a silent out-of-string-bounds write (which will go undetected by CVF even if you do have array&string bounds checking).I suggest always using CHARACTER(*) form for dummy arguments (unless you don't have a good reason to do otherwise).
Jugoslav
0 Kudos
Reply