Ken Thompson Mon, 16 Feb 2004 08:15:11 -0500
>> We continually get new subscribers who somehow have the expectation
>> that somehow CGF is responsible for fixing all problems.
My experience using and contributing to OSS has created expectations
that
* projects advance faster when their leaders encourage assistance from
the community and bootstrap members' attempts to assist better (e.g.
Pechtchanski), not when they belittle members' skills (e.g. Faylor).
* occasionally members (e.g. Thompson) will suck up to the leaders
* regressions will be corrected. I am certainly (and demonstrably)
willing to assist this process; the need for the process is
unquestionable (except for the latter clique).
Regarding the regression-correction process:
Christopher Faylor Mon, 16 Feb 2004 09:49:19 -0500
> What you have discovered is that when memcpy is given a NULL pointer
> it will [cause] a SEGV.
No, I have discovered considerably more. Consequently my question is,
is the path_conv bad?
Thomas L Roche Mon, 16 Feb 2004 00:01:10 -0500
>>> (gdb) where
>>> #0 memcpy () at
../../../../../../newlib/libc/machine/i386/memcpy.S:53
>>> #1 0x61062a91 in path_conv::set_normalized_path(char const*)
(this=0x616a2008,
>>> path_copy=0x64964edc
"/usr/src/unzip-5.50/.inst/runtimes/base_v5/installedApps/localhost/adminconsole.ear/adminconsole.war/com.ibm.ws.console.webservices/nl/zh_TW/504x.gif")
at ../../../../winsup/cygwin/path.cc:425
>>> #2 0x61027e81 in fhandler_base::set_name(path_conv&)
(this=0x616a1fcc, [EMAIL PROTECTED])
>>> at ../../../../winsup/cygwin/fhandler.cc:151
<snip>
>>> (gdb) up
>>> #1 0x61062a91 in path_conv::set_normalized_path(char const*)
(this=0x616a2008,
>>> path_copy=0x64964edc
"/usr/src/unzip-5.50/.inst/runtimes/base_v5/installedApps/localhost/adminconsole.ear/adminconsole.war/com.ibm.ws.console.webservices/nl/zh_TW/504x.gif")
at ../../../../winsup/cygwin/path.cc:425
>>> 425 memcpy (normalized_path, path_copy, n);
memcpy has 3 args, of which we can see 2 below:
<snip>
>>> (gdb) info frame
>>> Stack level 1, frame at 0x22ea20:
>>> eip = 0x61062a91 in path_conv::set_normalized_path(char const*)
(../../../../winsup/cygwin/path.cc:425);
>>> saved eip 0x61027e81
>>> called by frame at 0x22ea40, caller of frame at 0x22e9f0
>>> source language c++.
>>> Arglist at 0x22ea18, args: this=0x616a2008,
>>> path_copy=0x64964edc
"/usr/src/unzip-5.50/.inst/runtimes/base_v5/installedApps/localhost/adminconsole.ear/adminconsole.war/com.ibm.ws.console.webservices/nl/zh_TW/504x.gif"
>>> Locals at 0x22ea18, Previous frame's sp is 0x22ea20
>>> Saved registers:
>>> ebx at 0x22e9dc, ebp at 0x22ea18, esi at 0x22e9e4, edi at 0x22e9e0,
eip at 0x22ea1c
>>> (gdb) info args
>>> this = (path_conv * const) 0x616a2008
>>> path_copy = 0x64964edc
"/usr/src/unzip-5.50/.inst/runtimes/base_v5/installedApps/localhost/adminconsole.ear/adminconsole.war/com.ibm.ws.console.webservices/nl/zh_TW/504x.gif"
>>> (gdb) info locals
>>> n = 150
so normalized_path is the null (confirmed below), no? If so,
why? Certainly
path_conv::set_normalized_path(char const*)
(../../../../winsup/cygwin/path.cc:425)
would seem to be suspect, but one notes that
>>> (gdb) up
>>> #2 0x61027e81 in fhandler_base::set_name(path_conv&)
(this=0x616a1fcc, [EMAIL PROTECTED])
>>> at ../../../../winsup/cygwin/fhandler.cc:151
>>> 151 pc.set_normalized_path (in_pc.normalized_path);
>>> (gdb) info frame
>>> Stack level 2, frame at 0x22ea40:
>>> eip = 0x61027e81 in fhandler_base::set_name(path_conv&)
(../../../../winsup/cygwin/fhandler.cc:151);
>>> saved eip 0x6101dee7
>>> called by frame at 0x22ea70, caller of frame at 0x22ea20
>>> source language c++.
>>> Arglist at 0x22ea38, args: this=0x616a1fcc, [EMAIL PROTECTED]
>>> Locals at 0x22ea38, Previous frame's sp is 0x22ea40
>>> Saved registers:
>>> ebx at 0x22ea2c, ebp at 0x22ea38, esi at 0x22ea30, edi at 0x22ea34,
eip at 0x22ea3c
>>> (gdb) info args
>>> this = (fhandler_base * const) 0x616a1fcc
>>> in_pc = (path_conv &) @0x616a22ff: {fileattr = 0, fs = {
>>> name_storage = '\0' <repeats 193 times>,
"\b\000\000\000¼\037ja\001\000\000\000\000\000\000\000/usr/src/unzip-5.50/.inst/buildFeatures/input/featu",
>>> root_dir_storage =
"res/com.ibm.etools.common.frameworks.feature/feature_pt_BR.properties",
'\0' <repeats 128 times>,
"\b\000\000\000Ä#ja\001\000\000\000\000\000\000\000/usr/src/unzip-5.50/.inst/buildFeatures/input/f",
flags_storage = 1970561381, serial_storage = 796091762, sym_opt_storage =
778923875,
* fhandler_base::set_name(path_conv&) have obviously bad (no?)
name_storage and root_dir_storage ...
>>> is_remote_drive_storage = 105, drive_type_storage = 1869575269},
path_flags = 1663988588,
>>> known_suffix = 0x6f6d6d6f <Address 0x6f6d6d6f out of bounds>, error
= 1919299182, dev = {
>>> name = 0x77656d61 <Address 0x77656d61 out of bounds>, {devn =
1936421487, {minor = 29295,
>>> major = 29547}},
... thus hosing the name it's trying to set, ...
>>> native = 0x6165662e
";__comp_ctor::(86,938):_ZN23tagMCI_VD_ESCAPE_PARMSAC1ERKS_;2A.;__base_ctor::(86,939)=#(86,932),(10,13),(86,935),(10,13);:_ZN23tagMCI_VD_ESCAPE_PARMSAC2Ev;2A.;__comp_ctor::(86,939):_ZN23tagMCI_VD_ESCAP"...,
mode = 1701999988, dev_on_fs = 47}, case_clash = 116,
* fhandler_base::set_name(path_conv&) has obvious path problems ...
>>> normalized_path = 0x5f74705f <Address 0x5f74705f out of bounds>,
normalized_path_size = 1882083906,
>>> path = "roperties", '\0' <repeats 128 times>,
"\b\000\000\000Ì$ja\001\000\000\000\000\000\000\000/usr/src/unzip-5.50/.inst/buildFeatures/input/features/com.ibm.etools.common.frameworks.feature/feature_pt_"}
... no?
* fhandler_base::set_name(path_conv&)'s caller,
build_fh_pc(path_conv&), has a correct-looking normalized_path, but
...
>>> (gdb) up
>>> #3 0x6101dee7 in build_fh_pc(path_conv&) ([EMAIL PROTECTED]) at
../../../../winsup/cygwin/dtable.cc:468
>>> 468 fh->set_name (pc);
<snip>
>>> (gdb) info args
>>> pc = (path_conv &) @0x22ea80: {fileattr = 4294967295, fs = {
>>> name_storage =
"NTFS\000\000#\000\000\000\000\000\004ë\"[EMAIL PROTECTED]
ê\"\000\001\001\001\001\224ë\"\000ôdûwð/øwÿÿÿÿ¤ë\"\000§Êùw\000\000#\000a\000\000P
[EMAIL PROTECTED]", '\0' <repeats 77 times>, "#", '\0'
<repeats 20 times>, root_dir_storage = "d:\\", '\0' <repeats 256 times>,
flags_storage = 459007,
>>> serial_storage = 3431808182, sym_opt_storage = 64,
is_remote_drive_storage = false,
>>> drive_type_storage = 3}, path_flags = 2214592778, known_suffix =
0x0, error = 0, dev = {
>>> name = 0x61006f30 "", {devn = 247, {minor = 247, major = 0}},
native = 0x61006f30 "", mode = 0,
... name and name_storage are problematic, and ...
>>> dev_on_fs = false}, case_clash = false,
>>> normalized_path = 0x64964edc
"/usr/src/unzip-5.50/.inst/runtimes/base_v5/installedApps/localhost/adminconsole.ear/adminconsole.war/com.ibm.ws.console.webservices/nl/zh_TW/504x.gif",
normalized_path_size = 0,
... normalized_path_size is definitely wrong (no?) and ...
>>> path =
"d:\\ProgramFiles\\Cygwin\\usr\\src\\unzip-5.50\\.inst\\runtimes\\base_v5\\installedApps\\localhost\\adminconsole.ear\\adminconsole.war\\com.ibm.ws.console.webservices\\nl\\zh_TW\\504x.gif\000lnk\000lnk\000Ì\037ja\000\000\021\000\000\000\000\000\230¨B\000\001\000\000\000"...}
... there is junk in path.
If path_conv is in fact bad, it would seem advisable to focus
debugging on build_fh_pc(path_conv&), which seems responsible for ...
building the path_conv, no? Or are there other loci for its failure?
If the path_conv is (contrary to appearances) good, it would seem
advisable to focus debugging on fhandler_base::set_name(path_conv&).
Am I missing something? Your assistance would be appreciated.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
