Re: XMCD (fwd)
Wichert Akkerman writes:
> Previously Xmcd Admin wrote:
> > The way to debug this would be to link xmcd with a debug version of
> > lesstif (compiled with -g), then run it under gdb. You need to be adept
> > at debugging C source, and have a copy of lesstif sources to work with.
> > Not for the faint of heart...
>
> Yup, that's the way to go.
>
> > If someone is willing to do this and find the bug in lesstif (and fix it),
> > I am sure the lesstif people will be grateful. There is a lesstif mailing
> > list that you can submit bug reports/fixes to:
>
> I've finally gotten my hands on another CD on which xmcd crashes. This
> brings the list of troublesome CD's to:
> Hole - Live through this
> Robert Miles - dreamland
> Genesis - We can't dance
> Eric Clapton - Unplugged
> ELO - Greatest Hits
> Madness - Divine Madness
> The Best of Don McLean
> Pink Floyd - A Momentary Lapse of Reason
> Pink Floyd - Delicate Sound of Thunder disc 2
>
> I'll see if I can find something. I'll also check if xmcd compiled
> with Motif 1.2.4 works correctly.
>
> Wichert.
In case you are not aware, I distribute xmcd binaries linked with
Motif 1.2.1 and they work fine (use the xmcd web site for downloads).
Another fellow (Raul Miller) has debugged this a bit with lesstif
and came to a conclusion which I'll attach below.
-Ti
--
\\ // XMCD - Motif CD player / CDA - Command line CD player
\\/ Ti Kan / AMB Research Laboratories
//\ E-mail: xmcd@amb.org
// \\ URL: http://sunsite.unc.edu/~cddb/xmcd/
-----------X snip X---------
> From rdm@test.legislate.com Sun Nov 9 01:23 GMT 1997
> Return-path: <uucp>
> Received: by bazooka.amb.org (Sendmail 8.8.2/AMB-1.5)
> id BAA14493; Sun, 9 Nov 1997 01:23:33 GMT
> Received: from test.legislate.com by bazooka.amb.org; Sat, 8 Nov 97 17:23 PST
> Received: from test.legislate.com by sgiblab.sgi.com via SMTP (940816.SGI.8.6.9/911001.SGI)
> id QAA04706; Sat, 8 Nov 1997 16:32:41 -0800
> Received: (qmail 22726 invoked by uid 1000); 9 Nov 1997 00:32:40 -0000
> Message-ID: <19971108193239.60615@hazel>
> Date: Sat, 8 Nov 1997 19:32:39 -0500
> From: Raul Miller <rdm@test.legislate.com>
> To: lesstif@hungry.com
> Cc: Wichert Akkerman <xmcd@bazooka.amb.org>,
> Luis Francisco Gonzalez <luisgh@cogs.susx.ac.uk>,
> Matt Thompson <mattyt@oz.net>, Alex Romosan <alex@juliet.fnal.gov>
> Subject: Re: Bug#14088: xmcd can't dance
> References: <19971022135130.46057@test.legislate.com> <19971023115220.25649@pc135a>
> Mime-Version: 1.0
> Content-Length: 5907
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> X-Mailer: Mutt 0.85
> In-Reply-To: <19971023115220.25649@pc135a>; from Wichert Akkerman on Thu, Oct 23, 1997 at 11:52:20AM +0200
> Status: RO
>
> Some time ago, I wrote:
> > > When I have Genesis' "We Can't Dance" in the drive (compaq ide atapi),
> > > xmcd goes into a fit of memory reallocation (which eventually will
> > > consistently fail) such that the user interface never becomes active.
>
> Since then, it's been determined that xmcd linked against motif
> doesn't have the problem, but xmcd linked against lesstif does.
>
> Today, I've gone in to attempt to debug the problem under gdb. I'm
> not familiar with the code for xmcd, nor for lesstif. Furthermore,
> I'm having some problems with gdb (which seems to be confused about
> where it's at in program -- it acts like some parts of the program were
> compiled with optimization turned on -- which may be the case, though I
> thought I turned all the -O2 into -g). Anyways, rather than spend any
> more time fooling around with the build environment, I've decided to
> play it by ear. Take what I say here as something less than completely
> authorative.
>
> Here's a backtrace from gdb a few seconds after it's hit the
> problem:
>
> (gdb) where
> #0 0x40282009 in __mremap ()
> #1 0x402a405c in _dl_global_scope_alloc ()
> #2 0x40250181 in realloc ()
> #3 0x400ed917 in XtRealloc ()
> #4 0x4009bca9 in _XmTextUpdateLineTable ()
> at ../../../lib/Xm/shared/../../../lib/Xm/Text.c:1092
> #5 0x4009d418 in XmTextSetString ()
> at ../../../lib/Xm/shared/../../../lib/Xm/Text.c:1483
> #6 0x8051209 in dbprog_structupd (s=0x809a474) at dbprog.c:268
> #7 0x8052688 in dbprog_dbget (s=0x809a474) at dbprog.c:1085
> #8 0x8084c29 in slioc_disc_ready (s=0x809a474) at slioc.c:1915
> #9 0x808896d in slioc_start (s=0x809a474) at slioc.c:4116
> #10 0x806e865 in di_start (s=0x809a474) at libdi.c:856
> #11 0x804d583 in cd_start (s=0x809a474) at cdfunc.c:2068
> #12 0x805b863 in main (argc=1, argv=0xbffffd4c) at main.c:205
> (gdb)
>
> There appear to be two calls to XtRealloc from lib/Xm/Text.c's
> _XmTextUpdateLineTable, one on line 1166 (word wrapping on), the other
> on line 1230 (word wrapping off). I think word wrap is off, but
> haven't bothered to confirm (shouldn't make much difference from
> my point of view).
>
> After I let the XtRealloc complete, the widget looks like this:
>
> (gdb) p *(XmTextWidget)$esi
> $43 = {core = {self = 0x80ec528, widget_class = 0x400d1ff8,
> parent = 0x80e7ea8, xrm_name = 1789, being_destroyed = 0 '\000',
> destroy_callbacks = 0x0, constraints = 0x80ec6bc, x = 0, y = 0,
> width = 158, height = 33, border_width = 0, managed = 1 '\001',
> sensitive = 1 '\001', ancestor_sensitive = 1 '\001', event_table = 0x0,
> tm = {translations = 0x811c868, proc_table = 0x811c888,
> current_state = 0x0, lastEventTime = 0}, accelerators = 0x0,
> border_pixel = 0, border_pixmap = 2, popup_list = 0x0, num_popups = 0,
> name = 0x80afc6c "discTitleText", screen = 0x80a0220, colormap = 35,
> window = 0, depth = 16, background_pixel = 48631, background_pixmap = 2,
> visible = 1 '\001', mapped_when_managed = 1 '\001'}, primitive = {
> foreground = 0, shadow_thickness = 2, top_shadow_color = 65535,
> top_shadow_pixmap = 0, bottom_shadow_color = 23275,
> bottom_shadow_pixmap = 2, highlight_thickness = 2,
> highlight_color = 39321, highlight_pixmap = 0, help_callback = 0x80ec790,
> user_data = 0x0, traversal_on = 1 '\001', highlight_on_enter = 0 '\000',
> have_traversal = 0 '\000', unit_type = 0 '\000',
> navigation_type = 1 '\001', highlight_drawn = 0 '\000',
> highlighted = 0 '\000', highlight_GC = 0x80ec7f0,
> top_shadow_GC = 0x80ec920, bottom_shadow_GC = 0x80ec888}, text = {
> source = 0x80ecc08, activate_callback = 0x80e6dc8,
> focus_callback = 0x80ecbc8, losing_focus_callback = 0x81224c0,
> value_changed_callback = 0x80e66a8, modify_verify_callback = 0x80e52f8,
> wcs_modify_verify_callback = 0x0, motion_verify_callback = 0x0,
> gain_primary_callback = 0x0, lose_primary_callback = 0x0, value = 0x0,
> wc_value = 0x0, margin_height = 5, margin_width = 5,
> cursor_position_x = 0, output_create = 0x400a6600 <_XmTextOutputCreate>,
> input_create = 0x400a2870 <_XmTextInputCreate>, top_character = 0,
> bottom_position = 2147483647, cursor_position = 2,
> max_length = 2147483647, edit_mode = 1,
> auto_show_cursor_position = 1 '\001', editable = 1 '\001',
> verify_bell = -1 'ÿ', add_mode = 0 '\000', traversed = 0 '\000',
> in_redisplay = 0 '\000', needs_redisplay = 1 '\001',
> in_refigure_lines = 0 '\000', needs_refigure_lines = 1 '\001',
> in_setvalues = 0 '\000', in_resize = 0 '\000', in_expose = 0 '\000',
> highlight_changed = 0 '\000', pendingoff = 0 '\000', char_size = 0 '\000',
> on_or_off = on, output = 0x80ecb80, input = 0x80ecbe8, first_position = 0,
> last_position = 25, forget_past = 0, force_display = 0, new_top = 0,
> last_top_char = 0, dest_position = 0, disable_depth = 0,
> pending_scroll = 0, total_lines = 1, top_line = 0, vsbar_scrolling = 0,
> number_lines = 1, maximum_lines = 16, line = 0x8124a28, repaint = {
> number = 0, maximum = 0, range = 0x0}, highlight = {number = 0,
> maximum = 32, list = 0x80ecf18}, old_highlight = {number = 0,
> maximum = 0, list = 0x0}, inner_widget = 0x80eca50,
> line_table = 0x7b755008, table_size = 190208, table_index = 0}}
> (gdb) p *((XmTextWidget)$esi)->text->line_table
> $44 = {start_pos = 0, virt_line = 0}
> (gdb)
>
> Since the code has been running for quite a while (several seconds into
> the problem), I'm presuming that the problem is that the loop condition:
> while (end >= start)
> isn't being satisfied, and never will be. Since _XmTextUpdateLineTable
> never returns, I'm reasonably confident that I've at least located the
> problem region.
>
> Can you solve it from here?
>
> Also it would be nice if there were an obvious way of building this
> thing with debugging enabled (though that might be more the fault of
> the debian build environment for lesstif than anything in lesstif
> itself).
>
> Thanks,
>
> --
> Raul
>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . Trouble?
e-mail to templin@bucknell.edu .
Reply to: