[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [photran] Photran debugger problems---not sure where the problem is
|
Greg,
Thank you for pointing this out. I have managed to reproduce this bug
in pure C. It behaved exactly as expected given my Fortran diagnosis.
A really, really simple C project. The entire code is as follows:
1 #include <stdio.h>
2
3 int main( ) {
4 int i;
5 printf( "Help\n" );
6
7 for ( i=0; i<5000; i++ ) {
8 printf( "Number: %i %i\n", 5*i, i*i );
9 }
10 printf("Test breakpoint error!\n");
11 return 0;
12}
(line numbers clearly not in original, but I added them for clarity in
the next paragraph).
Placing breakpoints at lines 5 and 10 produces the following effects:
I stop at line 5. I start stepping through the loop and quickly get
bored; no output appears as you do so. If you then let the program
run, it hangs, with the last few lines being:
Number: 15720 9884736
Number: 15725 9891025
Numb85*stopped,reason="breakpoint-hit",bkptno="2",thread-id="1",frame={addr="0x004011df",func="main",args=[],file="../test.c",fullname="/cygdrive/d/Documents
and Settings/ja21673.MITLL/workspace/CTest/test.c",line="10"}
This is pretty clearly a problem with the way the debugger and program
outputs are interacting, especially with the odd way the programs
outputs get sent to the console asynchronously with the debugger. I
agree wholeheartedly; send it over to the CDT project. That's clearly
where the problem lies. How would I do that, exactly?
James
On Fri, May 6, 2011 at 1:56 PM, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
> James,
>
> The reason that you're not getting a lot of feedback on the debugger problem is that the debugger you're using is actually part of the C/C++ Development Tools (CDT) project, not Photran. What I would suggest you do is try creating a C project, compiling (obviously with a C compiler), then debugging it using a C/C++ Application launch configuration.
>
> If you see similar problems, then we could open a bug against the CDT debugger and someone from the CDT project would take a look at it. If it works without any problems, then we know it is something to do with using gdb on your system to debug a Fortran program. We would then have a chance of tracking down the offending output and possibly getting it fixed in CDT also.
>
> Regards,
> Greg
>
>
> On May 6, 2011, at 1:11 PM, James Hart wrote:
>
>> Hello everybody,
>>
>> I think I've worked out the fundamental behavior causing the problem.
>> No idea how to fix it, but I'm 99% certain I am absolutely correct.
>> All the facts fit.
>>
>> It's basically that the output to the console, when using print, is
>> oddly asynchronous (perhaps due to threads?), and worse, seems to
>> interact with the gdb debugging session console output. The result is
>> that when I produce console output in a loop, a large chunk of it gets
>> written to the same console that the gdb/mi interface uses. I guess
>> that "under the covers", they're really the same console session; I
>> should have realized. One of the things that doesn't get output is a
>> *newline* character. Thus the gdb command telling the system that
>> it's stopped at a breakpoint appears after some of the output from the
>> running fortran code, and thus is not recognized by eclipses gdb
>> parser. Thus the system hangs; Eclipse does not realize that the
>> debugger is at a breakpoint, and thus activates none of the
>> appropriate buttons, while the debugger sits there twiddling its
>> thumbs at the breakpoint.
>>
>> I can tell this is what is happening because I turned verbose debugger
>> output on, and recognize that the breakpoint stop command has, for
>> some reason, been appended to an (incomplete) version of the text my
>> code is producing, all in the same console.
>>
>> I hope this is specific enough that somebody can fix it. For my
>> purposes, I simply need to use demo code that doesn't use console
>> output, and I should be just dandy. Everything else seems to actually
>> work, despite the annoying error messages.
>>
>> James Hart
>>
>> On Fri, May 6, 2011 at 11:19 AM, James Hart <jamesahart79@xxxxxxxxx> wrote:
>>> Everybody,
>>>
>>> A follow up to me previous email.
>>>
>>> I've tried several fixes, none of which have changed the behavior of
>>> the bug in the slightest.
>>>
>>> I searched through the archives of this mailing list, and found the
>>> possibility that I would have to switch to an older JRE such as
>>> version 5, release 13. When I did this switch, nothing changed.
>>>
>>> Also, I realized I was running the program as a 32 bit program on a 64
>>> bit machine. I tried reinstalling everything with 64 bit options
>>> whenever the option was given. Also no change in behavior.
>>>
>>> Please, any help out there? Documentation is extremely sparse, and I
>>> would really like to bring my development environment into the 21
>>> century. These bugs are just killing me, though. If they aren't
>>> resolved, I'll have to pull back emphatically on any push for
>>> adoption.
>>>
>>> James Hart
>>>
>>> On Thu, May 5, 2011 at 1:54 PM, James Hart <jamesahart79@xxxxxxxxx> wrote:
>>>> Hello,
>>>>
>>>> I have been recently inspecting Photran to see how it handles in
>>>> real-world environments. I really like the idea of using Eclipse as
>>>> the basis for a large number of reasons, including the possibility of
>>>> expanding the functionality for in-house projects. Unfortunately, I
>>>> am having some serious issues with the debugger that make it
>>>> essentially useless for me needs as is currently stands.
>>>>
>>>> There are several different problems I have found, which do not
>>>> reassure me. However, I consider it likely that these problems are
>>>> due as much to my particular configuration as anything else. I have a
>>>> Windows XP 64 bit system with the gfortran and gdb debugger installed
>>>> as per the directions on the website.
>>>>
>>>> My game-breaker bugs is as follows:
>>>>
>>>> (1) When I place a debug point, some of the information from the
>>>> debugger apparently leaks over into the output console. The timing is
>>>> unpredictable, but repeatable with the same code. This would be a
>>>> minor problem if it weren't for the fact that the program also
>>>> sometimes hangs when this happens. When is again unpredictable; it
>>>> depends in my particular case how many lines have breakpoints, and
>>>> which lines they are. This is unacceptable.
>>>>
>>>> In my case, the last line of output from my simple console app looks like:
>>>>
>>>> Number 2205 0.50000149
>>>> 1738*stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={addr="0x0040135e",func="entry",args=[],file="../entry.f90",fullname="/cygdrive/d/Documents
>>>> and Settings/ja21673.MITLL/workspace/first_test/entry.f90",line="15"}
>>>>
>>>>
>>>> Several other (maybe related) irritants:
>>>>
>>>> (2) The output from the execution console is not encouraging, and
>>>> means almost nothing to me. My most recent session produced the
>>>> output:
>>>>
>>>> cygwin warning:
>>>> MS-DOS style path detected: D:\Documents and
>>>> Settings\ja21673.MITLL\workspace\first_test
>>>> Preferred POSIX equivalent is: /cygdrive/d/Documents and
>>>> Settings/ja21673.MITLL/workspace/first_test
>>>> CYGWIN environment variable option "nodosfilewarning" turns off this warning.
>>>> Consult the user's guide for more details about POSIX paths:
>>>> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
>>>> .gdbinit: No such file or directory.
>>>> auto-solib-add on
>>>> Undefined command: "auto-solib-add". Try "help".
>>>> [New thread 5744.0x1194]
>>>> Error: dll starting at 0x77d40000 not found.
>>>> Error: dll starting at 0x77d40000 not found.
>>>> Error: dll starting at 0x77c20000 not found.
>>>> Error while mapping shared library sections:
>>>> /cygdrive/c/WINDOWS/SysWOW64/ntdll32.dll: No such file or directory.
>>>> [New thread 5744.0xde0]
>>>> Current language: auto; currently fortran
>>>> A syntax error in expression, near `.0'.
>>>>
>>>> (3) When I select an element of an array, this last part of the
>>>> console output is produced.
>>>>
>>>> I can send you a copy of the program and the output, if you'd like;
>>>> they aren't very long. I don't know what else is relevant; the
>>>> makefile, maybe? I just used the autogenerated one.
>>>>
>>>> --
>>>> Nature hates being reified.
>>>>
>>>
>>>
>>>
>>> --
>>> Nature hates being reified.
>>>
>>
>>
>>
>> --
>> Nature hates being reified.
>> _______________________________________________
>> photran mailing list
>> photran@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/photran
>
> _______________________________________________
> photran mailing list
> photran@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/photran
>
--
Nature hates being reified.
