[
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 and everybody,
I have submitted the bug with the CDT team. I also tested it with the
gdb command line interface, and could *not* reproduce it. It appears
to be more and more certain that it is caused by some interaction
between gdb/mi and Eclipse CDT.
Thank you everybody who responded. For my purposes and for the
moment, I am completely satisfied and appreciate the help I was given.
If I ever find something that requires specific help from you folks,
I won't hesitate to ask!
James
On Fri, May 6, 2011 at 3:29 PM, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
> 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
>
> _______________________________________________
> photran mailing list
> photran@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/photran
>
--
Nature hates being reified.
