Re: [photran] Photran debugger problems---not sure where the problem is

[James Hart <jamesahart79@xxxxxxxxx>]

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.