From Serge.Dussud at Sun.COM Tue Dec 2 18:04:51 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Tue, 02 Dec 2008 17:04:51 +0100 Subject: tsch cores if nscd disabled on Solaris LDAP sasl/gssapi client Message-ID: <49355CA3.3030409@Sun.COM> hello tcsh-bugs, we've seen bash and tcsh core dumping under certain conditions on solaris 10 (and newer), because of multiple malloc() routines issues with certain ld(1) options. For gory details, please refer the discussion on bash-bugs at gnu.org: http://thread.gmane.org/gmane.comp.shells.bash.bugs/11855 and to the bug referred in [1]. The preferred solution to this issue seems to be to compile tcsh with -DSYSMALLOC on Solaris. so my question to you at this point is the same I posted earlier today to bash-bugs: are there any real benefits these days of using tcsh's own malloc function rather than the one from the system ? or, otherwise said, what do tcsh lose when it's compiled with option -DSYSMALLOC ? TIA ! Serge [1] related bugs: tcsh: http://bugs.opensolaris.org/view_bug.do?bug_id=6661116 linker: http://bugs.opensolaris.org/view_bug.do?bug_id=6778453 bash: http://bugs.opensolaris.org/view_bug.do?bug_id=6722392 From christos at zoulas.com Wed Dec 3 17:49:11 2008 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 3 Dec 2008 10:49:11 -0500 Subject: tsch cores if nscd disabled on Solaris LDAP sasl/gssapi client In-Reply-To: <49355CA3.3030409@Sun.COM> from Serge Dussud (Dec 2, 5:04pm) Message-ID: <20081203154911.67F1A5654E@rebar.astron.com> On Dec 2, 5:04pm, Serge.Dussud at Sun.COM (Serge Dussud) wrote: -- Subject: tsch cores if nscd disabled on Solaris LDAP sasl/gssapi client | | hello tcsh-bugs, | | we've seen bash and tcsh core dumping under certain conditions on | solaris 10 (and newer), because of multiple malloc() routines issues | with certain ld(1) options. For gory details, please refer the | discussion on bash-bugs at gnu.org: | | http://thread.gmane.org/gmane.comp.shells.bash.bugs/11855 | | and to the bug referred in [1]. | | The preferred solution to this issue seems to be to compile tcsh with | -DSYSMALLOC on Solaris. so my question to you at this point is the same | I posted earlier today to bash-bugs: are there any real benefits these | days of using tcsh's own malloc function rather than the one from the | system ? or, otherwise said, what do tcsh lose when it's compiled with | option -DSYSMALLOC ? | | TIA ! | Serge Well, the preferred solution should be to fix RTLD_GROUP semantics so that they don't break existing applications and not having to mark themselves as interposers :-) I would like to see real justification for changing the linker semantics and a big "HEADS UP", instead of introducing the broken semantics and see what breaks. You lose a little functionality, such as range checks, localized error messages, but SYSMALLOC works. The option is there for broken systems where tcsh cannot override the provided malloc implementation. christos From mikets at frontline-pcb.com Thu Dec 4 18:54:16 2008 From: mikets at frontline-pcb.com (Michael Tseitlin) Date: Thu, 4 Dec 2008 18:54:16 +0200 Subject: Running commands with UTF8 parameters Message-ID: <830C82B0B852B9488F0A944853D4D012055FD968@uganda.FRONTLINE-PCB.COM> I try to run commands and pass non-ASCII utf8 parameters on Windows XP. The command receives a command line and has parameters with question marks instead of original values. For example: "myapp.exe abc???" results in "abc???" After debugging, I found out the cause - the call to SetFileApisToOEM() at tcsh.exe startup (win32/support.c). When commenting out the call - the parameters are passed as expected. Do you think it's legal requirement to have UTF8 parameters? What can be another solution to pass such parameters? Do you think this fix (removing the call) is legitimate? Isn't it better to have an environment variable to control this? Thanks, Michael From christos at zoulas.com Thu Dec 4 20:09:02 2008 From: christos at zoulas.com (Christos Zoulas) Date: Thu, 4 Dec 2008 13:09:02 -0500 Subject: Running commands with UTF8 parameters In-Reply-To: <830C82B0B852B9488F0A944853D4D012055FD968@uganda.FRONTLINE-PCB.COM> from "Michael Tseitlin" (Dec 4, 6:54pm) Message-ID: <20081204180902.E6D475654E@rebar.astron.com> On Dec 4, 6:54pm, mikets at frontline-pcb.com ("Michael Tseitlin") wrote: -- Subject: Running commands with UTF8 parameters I don't know. Amol should know. christos From mikets at frontline-pcb.com Sun Dec 7 12:32:56 2008 From: mikets at frontline-pcb.com (Michael Tseitlin) Date: Sun, 7 Dec 2008 12:32:56 +0200 Subject: Problem recognizing GUI applications on Windows in 6.16 Message-ID: <830C82B0B852B9488F0A944853D4D012055FDB20@uganda.FRONTLINE-PCB.COM> It seems that 6.16 source has a bug in win32/globals.c is_gui() The return value check of ReadFile has been dropped between 6.15 and 6.16. As a result, the CHECK_IO macro and wait_for_io function behave incorrectly. In order to fix, either the check for ReadFile result should be added back or wait_for_io function should compare result of GetLastError with SUCCESS. Regards, Mikets From Serge.Dussud at Sun.COM Tue Dec 16 16:34:17 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Tue, 16 Dec 2008 15:34:17 +0100 Subject: tsch cores if nscd disabled on Solaris LDAP sasl/gssapi client In-Reply-To: <20081203154911.67F1A5654E@rebar.astron.com> References: <20081203154911.67F1A5654E@rebar.astron.com> Message-ID: <4947BC69.9020806@Sun.COM> On 12/ 3/08 04:49 PM, Christos Zoulas wrote: > On Dec 2, 5:04pm, Serge.Dussud at Sun.COM (Serge Dussud) wrote: > -- Subject: tsch cores if nscd disabled on Solaris LDAP sasl/gssapi client > > | > | hello tcsh-bugs, > | > | we've seen bash and tcsh core dumping under certain conditions on > | solaris 10 (and newer), because of multiple malloc() routines issues > | with certain ld(1) options. For gory details, please refer the > | discussion on bash-bugs at gnu.org: > | > | http://thread.gmane.org/gmane.comp.shells.bash.bugs/11855 > | > | and to the bug referred in [1]. > | > | The preferred solution to this issue seems to be to compile tcsh with > | -DSYSMALLOC on Solaris. so my question to you at this point is the same > | I posted earlier today to bash-bugs: are there any real benefits these > | days of using tcsh's own malloc function rather than the one from the > | system ? or, otherwise said, what do tcsh lose when it's compiled with > | option -DSYSMALLOC ? > | > | TIA ! > | Serge > > Well, the preferred solution should be to fix RTLD_GROUP semantics it's indeed work in progress. > so that they don't break existing applications and not having to > mark themselves as interposers :-) I would like to see real > justification for changing the linker semantics and a big "HEADS > UP", instead of introducing the broken semantics and see what > breaks. > > You lose a little functionality, such as range checks, localized > error messages, but SYSMALLOC works. The option is there for broken > systems where tcsh cannot override the provided malloc implementation. OK, thanks. Serge > > christos