Bug 728 - RUI in _X11TransSocketINETGetAddr at lines 371, 379, 441 etc. in file "Xtranssock.c"
Summary: RUI in _X11TransSocketINETGetAddr at lines 371, 379, 441 etc. in file "Xtrans...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/other (show other bugs)
Version: git
Hardware: SPARC Solaris
: high normal
Assignee: Xorg Project Team
QA Contact:
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks: 8184
  Show dependency treegraph
 
Reported: 2004-06-06 21:59 UTC by Roland Mainz
Modified: 2006-09-13 14:10 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch to Xtranssock.c (707 bytes, patch)
2005-10-09 13:42 UTC, Alan Coopersmith
no flags Details | Splinter Review

Description Roland Mainz 2004-06-06 21:59:14 UTC
2004-06-06-trunk on Solaris 2.8/SPARC compiled with Sun Workshop 8.
While testing a sample application ("Xman") I am getting the following RUI when
running the application under dbx's 'check -all'-control:
-- snip --
xc/programs/xman% (export LANG=en_US LC_ALL=en_US ; export
XPSERVERLIST=meridian:35 ;
XENVIRONMENT=/shared/bigtmp/xorg/work_xman_printtest/xc/programs/xman/Xman.ad
LD_LIBRARY_PATH=$PWD/../../exports/lib/ dbx ./xman)
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.1' in your .dbxrc
Reading xman
Reading ld.so.1
Reading libXaw.so.7.0
Reading libXmu.so.6.2
Reading libXt.so.6.0
Reading libSM.so.6.0
Reading libICE.so.6.3
Reading libXpm.so.4.11
Reading libXp.so.6.2
Reading libXext.so.6.4
Reading libX11.so.6.2
Reading libc.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libdl.so.1
Reading libmp.so.2
Reading libc_psr.so.1
(dbx) check -all
access checking - ON
memuse checking - ON
(dbx) run
Running: xman 
(process id 15896)
Reading librtc.so
RTC: Enabling Error Checking...
RTC: Running program...
Read from uninitialized (rui):
Attempting to read 2 bytes at address 0xffbece18
    which is 136 bytes above the current stack pointer
Variable is 'socknamev6'
stopped in _X11TransSocketINETGetAddr at line 371 in file "Xtranssock.c"
  371           ciptr->family = ((struct sockaddr *)socknamePtr)->sa_family;
(dbx) where
=>[1] _X11TransSocketINETGetAddr(ciptr = 0x7dd00), line 371 in "Xtranssock.c"
  [2] _X11TransSocketINETConnect(ciptr = 0x7dd00, host = 0x7cbd0 "meridian",
port = 0xffbed098 "6000"), line 1744 in "Xtranssock.c"
  [3] _X11TransConnect(ciptr = 0x7dd00, address = 0xffbee78c "tcp/meridian:0"),
line 863 in "Xtrans.c"
  [4] _X11TransConnectDisplay(display_name = 0xffbef30e "meridian:0.0",
fullnamep = 0xffbee99c, dpynump = 0xffbee998, screenp = 0xffbee994, auth_namep =
0xffbee980, auth_namelenp = 0xffbee978, auth_datap = 0xffbee97c, auth_datalenp =
0xffbee974), line 368 in "ConnDis.c"
  [5] XOpenDisplay(display = (nil)), line 159 in "OpenDis.c"
  [6] XtOpenDisplay(app = 0x7be40, displayName = (nil), applName = (nil),
className = 0x304b4 "Xman", urlist = 0x41e78, num_urs = 9U, argc = 0xffbeecbc,
argv = 0xffbeecdc), line 258 in "Display.c"
  [7] _XtAppInit(app_context_return = 0xffbeeb80, application_class = 0x304b4
"Xman", options = 0x41e78, num_options = 9U, argc_in_out = 0xffbeecbc,
argv_in_out = 0xffbeebe0, fallback_resources = 0x41f08), line 331 in "Display.c"
  [8] XtOpenApplication(app_context_return = 0xffbeec70, application_class =
0x304b4 "Xman", options = 0x41e78, num_options = 9U, argc_in_out = 0xffbeecbc,
argv_in_out = 0xffbeecdc, fallback_resources = 0x41f08, widget_class =
0xf85a02b0, args_in = (nil), num_args_in = 0), line 973 in "Initialize.c"
  [9] XtAppInitialize(app_context_return = 0xffbeec70, application_class =
0x304b4 "Xman", options = 0x41e78, num_options = 9U, argc_in_out = 0xffbeecbc,
argv_in_out = 0xffbeecdc, fallback_resources = 0x41f08, args_in = (nil),
num_args_in = 0), line 1012 in "Initialize.c"
  [10] main(argc = 1, argv = 0xffbeecdc), line 157 in "main.c"
-- snip --

Continuing results in a 2nd RUI:
-- snip --
Read from uninitialized (rui):
Attempting to read 1 byte at address 0xffbece18
    which is 136 bytes above the current stack pointer
Variable is 'socknamev6'
stopped in _X11TransSocketINETGetAddr at line 379 in file "Xtranssock.c"
  379       memcpy (ciptr->addr, socknamePtr, ciptr->addrlen);
-- snip --

and a 3rd:
-- snip --
(dbx) cont
Read from uninitialized (rui):
Attempting to read 1 byte at address 0xffbece08
    which is 120 bytes above the current stack pointer
Variable is 'socknamev4'
stopped in _X11TransSocketINETGetPeerAddr at line 441 in file "Xtranssock.c"
  441       memcpy (ciptr->peeraddr, socknamePtr, ciptr->peeraddrlen);
-- snip --
(NOTE: the machine has no IPv6 transport configured).
Comment 1 Alan Coopersmith 2005-10-09 13:42:40 UTC
Created attachment 3527 [details] [review]
Patch to Xtranssock.c

As best as I can tell, this is dbx being unable to recognize that the kernel
filled in those values in the getsockname/getpeername/etc. system calls.
The attached patch clears many of these by simply zeroing out the structs in
user space before asking the kernel to fill in the real values, but other than
removing false alarms, I'm not sure it's useful.
Comment 2 Alan Coopersmith 2006-09-13 14:10:32 UTC
Committed fix to modular head for upcoming 7.2 release:

commit b4c6bd92b3a8bed746da641c59a9f040e1d83768
Author: Alan Coopersmith <alan.coopersmith@sun.com>
Date:   Wed Sep 13 14:09:22 2006 -0700

    Bug 728: RUI in _X11TransSocketINETGetAddr in file "Xtranssock.c"

    Bug #728: <https://bugs.freedesktop.org/show_bug.cgi?id=728>
    Patch #3527: <https://bugs.freedesktop.org/attachment.cgi?id=3527>
    bzero sockaddr structures before passing to kernel to convince memory
    checkers that they are initialized before use


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.