# $Id$ -*- Text -*-
# The list of reported DDD bugs (not yet reproduced).

Note: For problems occurring when *building* DDD, see the file `PROBLEMS'.
      For known bugs that could be reproduced, see the file `BUGS'.

This is a list of reported DDD bugs which could not yet be reproduced.
Feel free to investigate into one of these problems or send in more
detail.

-- list starts here --
706 Harry Mangalam <mangalam@uci.edu> reports: As soon as I click on
    a variable to try to highlight a structure name, DDD 2.1 goes
    into an unresponsive state for several seconds (seems like up to
    a minute on a 486) in which the ddd process hogs the cpu.  It
    then returns to a usable state until the next time I try to
    highlight a variable name.  It seems that if I click on a simple
    variable name, it responds appopriately, but if I try to
    drag-hilite the name, ddd goes berserk with the cpu.

708 Nagi M. Aboulenein <naboulen@ichips.intel.com> says: I'm seeing a
    persistent problem with various version of DDD on FreeBSD/x86
    platforms. The problem occurs when an attempt is made to save
    options. At that point DDD dies and the options file is not
    updated.

709 Lev Makhlis <mlev@writeme.com> states that DDD 2.2.3
    (i586-pc-linux-gnulibc1) consistently crashes if he runs it when
    no `~/.ddd/' exists.

711 Brian Dowtin <Private_User@gilbarco.com> reports that on 
    SCO Server 5 and running DDD somehow the breakpoint pixmap
    'sticks' to the window.  Sometime after setting a breakpoint, The
    stop sign, stays in one spot. If I scroll up or down, its
    there. If I delete the actual breakpoint its still there. If I
    resize/close//reopen source window, its still there. If I load a
    different source file - you get the picture.

712 Ralf Hildebrandt <R.Hildebrandt@tu-bs.de> reports that on his
    HP-UX box, the tooltips are not complete: "Set/Delete Breakpo???",
    "Display/Undisplay???", etc.

717 Lassi A. Tuura <lat@iki.fi> states:

    On HP-UX and on DEC Unix everything is fine except that:

    - The default font I get is a bit big and clunky, the old one was
      much better (in case it matters, I have 100dpi fonts before
      75dpi fonts in my font path).  BTW, again this is only a problem
      on my HP-UX display (see the item below), not on the NT.

    - On data display window, the grayed out icons on the tool bar
      sometimes "disappear", i.e. don't show anything but the little
      arrow in the corner.  In more detail, the rotate icon disappears
      completely, undisplay is just a funny little light gray blob,
      and show/hide is somewhat larger but still unreadable blob.
      When enabled, all show just fine.  I would venture to guess that
      the problem is related to choosing right colors for them.  This
      is on on a 8-bit PseudoColor screen on workstation running HP-UX
      10.20.  On my Windows NT 4.0 running Exceed on 24-bit screen
      everything shows fine.

720 Jens Albrecht <Jens.Albrecht@informatik.uni-erlangen.de> complains 
    that using DBX, the `file' command does not change the source
    file.

721 Johan Vermeire <jvme@se.bel.alcatel.be> reports: `In ddd I
    tried to copy the whole contents of the command output buffer via
    the "select all" in ddd and to paste it into a UNIX editor for
    interpretation.  This results in: `gdb: write failed: Resource
    temporarily unavailable' messages until I kill the ddd process'.

722 Steffen Wieschalla <steffen.wieschalla@student.uni-tuebingen.de>
    uses ddd-2.99.99 with tvtwm-pl11 on Solaris 2.5.1.  He says: `If I
    start ddd, the window with the buttons "run", "stop", "step",
    "stepi", ... appears for a short time and then disappears. On
    e.g. fvwm it works correct. Does someone have an idea?'

724 Art Werschulz <agw@dsm.fordham.edu> reports a huge command tool on 
    his DEC Alpha system using fvwm.  The problem happens with fvwm
    and tvwm, but not with fvwm95, mwm or olwm.  [WM bug?]

726 jik- <fract@sprintmail.com> reports that calling `editres' on DDD
    makes it dump core.

727 Mihai Budiu <mihaib@gs41.sp.cs.cmu.edu> reports:

    1) The history window of '()' (which you can pop down using the
       arrow in the right) won't go away unless you type something in
       the () box; the history window remains on top even if you lower
       the whole DDD window.

    6) Sometimes when I display '*this' after each 'Next' or 'Step'
       all the displayed fields of '*this' are automatically hidden,
       which is very annoying.  This doesn't happen always, and I'm
       not sure if it happens with other pointers than 'this'.  I
       could not reproduce the bug now.

729 Derrik Pates <dmp8309@silver.sdsmt.edu> says:

    First menu click in any menu forces window to move downward and
    the menu to appear where it normally would have, had the window
    not moved. (in separate windows mode)

    Enabling clustering in the Preferences window in Separate windows
    mode causes the data window to be forced to the top (doesn't get
    focus, but goes to top immediately). The same does not happen when
    clustering is being disabled

    This doesn't really classify as a bug, but it still does not
    properly handle array pointers. Can this be fixed?
    
    When I start up in separate windows mode, the DDD debugger console
    window appears, but it doesn't get the input focus.

730 Rubber_Buccaneer@Galactic.Headquarters.org thinks that the window
    containing the short cut buttons, i.e. step, next, etc. should
    always be displayed on top of the main window: `If the main window
    is lowered the short cut box is lowered too, but when the main
    window is raised the short cut box remains lowered. It was only
    through accidentally clicking on the border of the tear-off help
    menu that I discovered this, as the tear-off help window and the
    short cuts box are clearly related.'

731 Jarkko Hietaniemi <jhi@iki.fi> says:
    When the ddd 3.0.90 (compiled with g++/stdc++ in Solaris 2.6 from the
    sources) is started, it interacts strangely with my X11 window manager
    (vtwm Release 5.4.4c (http://www.visi.com/~hawkeyd/vtwm.html), running
    in NetBSD 1.3.2, XFree86 3.3.2).

    Definition of strange: the splash screen starts up nicely in my
    current virtual screen but the DDD main window makes my vtwm to jump
    to screen #0 (upper left corner).

    I have never before seen problems like this with vtwm.

732 Jacques Leroy <jle@star.be> reports that Electric Fence detects
    illegal memory accesses for strncpy(), strchr(), memchr() and
    possibly strcpy() on HPPA 712/60 + HPUX 9.03 + gcc 2.8.1.

733 Jochen Schtze <jos@gbf.de> complains that ^Z closes the execution 
    window immediately on DEC alpha OSF1 4.0 878.

734 Christoph Koegl <koegl@informatik.uni-kl.de> reports for the
    precompiled DDD 3.1 Sun Sparc Solaris 2.5.1 binary linked against
    OSF/Motif 2.0: If I open a plot window (via entering 'graph plot
    42') and activate any of the pull down menus after resizing the
    window the menu appears in the wrong place. This place changes
    sometimes after further resizings, sometimes it stays where it
    is. I could not yet (after 20 seconds of experimenting) see a
    pattern.

736 Charles Neil Harwick Ridgway <cnhr@ecs.soton.ac.uk> reports:
    (LessTif 0.87) I load up ddd in separated windows
    e.g. non-stacked. I load in a egcs-g++ compiled file (with -g) and
    the program is loaded in. DDD then justs sits there with an
    hour-glass symbol doing nothing. There is little or no process
    usage - it is just doing nothing! The only way I can kill it is by
    using the "kill -9" command.

737 Charles Neil Harwick Ridgway <cnhr@ecs.soton.ac.uk> reports:
    (LessTif 0.87) I use the file open dialog box to try and load in a
    file. I'm not in the correct directory and so I change to another
    (double-clicking doesn't seem to work - point with the mouse and
    press enter). I have a symbolic link to the directory with my code
    in. These are not shown in the file window. Out of frustation I
    clicked in the blank window and hey-presto core-dump. Woo-hoo.

742 (Insert new bugs here)
