[
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
|
James,
Have you tried running gdb from the command line and repeating this test? What happens?
I'm guessing you're using Eclipse 3.6 and CDT 7.0, right?
If you want to open a bug against CDT:
1. Create a bugzilla account: https://bugs.eclipse.org/bugs/createaccount.cgi
2. Log in using this account.
3. Create a new bug: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CDT
4. Choose cdt-debug for the component. Make sure your Hardware and OS are correct.
5. Fill in the Summary and Description fields then click on Submit Bug.
Regards,
Greg
On May 6, 2011, at 2:40 PM, James Hart wrote:
> 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.
> _______________________________________________
> photran mailing list
> photran@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/photran
