Skip to main content

[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,

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



Back to the top