Edward Pilatowicz wrote: [snip] > ps - normally i don't advertise bugs that i file, but in this case i'm > just venting. perhaps we should create a new rant-disc...@os.o > alias? (or perhaps that's an oxy-moron? may be it should just > be r...@os.o?)
BTW: http://bugs.opensolaris.org/view_bug.do?bug_id=6800929 ("snv_106 ksh93 update breaks Install(1M)") was caused by the change for http://bugs.opensolaris.org/view_bug.do?bug_id=6745015 ("*ksh93* VARIABLE=`command substitution` assignment is not reliable on OpenSolaris") which switched command substitutions ($(...)) from |mmap()|'ed files to pipes. As a result nearly 1/6 of the code in the shell core was changed and we needed around four weeks to drive out all kind of regressions and to ge the code finally passing the ksh93 + VSC test suites and building OS/Net, FOX, SFWNV and KDE when /sbin/sh is ksh93. Your bug (CR #6800929) slipped through the testing network... but with the putback for the fix we added a ksh93 test suite module (see http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libshell/common/tests/sun_solaris_cr_6800929_large_command_substitution_hang.sh) which explicitly tests for this kind of bug and in the meantime we've created an even more advanched version of the test (see http://svn.genunix.org/repos/on/branches/ksh93/gisburn/scripts/tests/sun_solaris_cr_6800929_large_command_substitution_hang.sh) which AFAIK covers all known cases related to CR #6800929 for both $(...) and ${...;}-style command substitutions and we created a more general test suite module (see http://svn.genunix.org/repos/on/branches/ksh93/gisburn/scripts/tests/sun_solaris_command_substitution.sh) to make sure we cover even general cases, too. And for each new bug we find we're trying to add new test modules to the ksh93 test suite to make sure we only have to fix them once... ... I'm sorry for the regressions we caused but we really try to learn from the mistakes and fill the gaps in the testing network. The same applies to CR #6805584 ("ksh93 in non-C locale breaks time/ptime") - we learned from the first ksh93-integration putback that we have "holes" in the ksh93 test suite related to memory corruption and ksh93-integration update1 therefore enabled libast's builtin memory corruption checks for the test suite runs (libast's malloc+other allocators have libumem-style memory checks builtin by default (controlled via the VMDEBUG/VMCHECK/etc- env vars)) but this didn't cover the |libc::malloc()| allocator (since libast-based applications don't use this, however the crash in CR #6805584 seems to happen deeply in libc and something seems to corrup the heap mananged by |libc::malloc()| (which wasn't originally anticipiated)). Therefore the next step will be to try to enable libumem for the ksh93 test suite run and add the use of /opt/onbld/bin/Install to our manual set of tests (and send you binary tarballs for testing before doing the next ksh93-integration update putback). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
