Bug#968825: mono-runtime: NullReferenceException in System.Linq.Enumerable.ToArray
Package: mono-runtime
Version: 5.18.0.240+dfsg-3
Severity: normal
Dear Maintainer,
When ToArray tries to convert an enumeration that was obtained as
concatination of an array and another enumeration, it hangs for
some time and then crashes due to Nill Reference exception.
See the attached example.
-- System Information:
Debian Release: 10.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-9-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mono-runtime depends on:
ii libc6 2.28-10
ii mono-runtime-sgen 5.18.0.240+dfsg-3
mono-runtime recommends no packages.
mono-runtime suggests no packages.
-- no debconf information
/*
* Mono version: Mono JIT compiler version 5.18.0.240 (Debian 5.18.0.240+dfsg-3
Wed Apr 17 16:37:36 UTC 2019)
*
* System.Linq.Enumerable.ToArray generates NullReferenceException when
converts IEnumerable to an array.
*/
using System;
using System.Collections.Generic;
using System.Linq;
public class Test
{
static IEnumerable Enumerable()
{
yield return 2;
}
public static void Main()
{
var array1 = new byte[] { 1 };
var enumerable = array1.Concat(Enumerable());
var array2 = enumerable.ToArray();
Console.WriteLine(array2.Length);
}
}
Bug#407722: status of libgit.a
On Sun, Mar 07, 2010 at 11:27:35AM +0100, Paul Menzel wrote: could you please give an update on the status of libgit.a. For example cgit still could not be packaged yet for Debian [1] because of this bug [2]. cgit is used by a lot of projects out there, so I am wondering if the current libgit.a can be released in its current state. By the way, is there a web site/page for libgit.a? libgit.a has never been meant to use outside of Git. It was created just to assist with the building process, and there is no clear defined API. So, using libgit.a outside of Git is no different than copying source files and using them in another project. AFAIK, there is no plan to create a stable API for the existing libgit.a Another project (libgit2) started some time ago to create a Git library with a stable API, but it does not share much code with Git, and so far it provides only basic functionality and has very few contributors, who are also busy with other projects. So, in no way it can be considered as a replacement of existing libgit.a. On the other hand, libgit.a includes plumbing functions, which may be considered as stable API. So, if cgit uses only those functions just to avoid fork(), it makes sense; but it should be done carefully, because libgit.a can call exit() on error. It may be not a problem for cgit, but it is just another reason why libgit.a cannot be considered as a general purpose library that provides Git functionality... Dmitry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507522: mingw32-runtime: missing type definitions in tchar.h
Hi Ron, You should probably report this one directly upstream, but before you do, please read: http://mingw.org/Reporting_Bugs ... in particular the part about them requiring you to provide references to the source of the information that you used to create this patch. Without such a reference to documentation that we can freely draw from to provide the missing symbols you require, I'm afraid they probably won't be able to apply this patch. A reference to MSDN is sufficient? http://msdn.microsoft.com/en-us/library/se784sk6.aspx As to __TCHAR_DEFINED - _TCHAR _TCHAR_DEFINED - TCHAR I believe it is common knowledge. As to the patch, those line of code where not copied from anywhere, but written by me. So, all mistakes are also mine. Sorry. Here is the corrected version of the patch: === --- tchar.h.orig2007-09-22 23:45:50.0 +0400 +++ tchar.h 2008-12-02 17:43:20.0 +0300 @@ -43,11 +43,21 @@ #ifndef _TCHAR_DEFINED #ifndef RC_INVOKED typedefwchar_t TCHAR; -typedef wchar_t _TCHAR; #endif /* Not RC_INVOKED */ #define _TCHAR_DEFINED #endif +#ifndef __TCHAR_DEFINED +#ifndef RC_INVOKED +typedef wchar_t_TCHAR; +typedef wchar_t_TSCHAR; +typedef wchar_t_TUCHAR; +typedef wchar_t_TXCHAR; +typedef wint_t _TINT; +#endif /* Not RC_INVOKED */ +#define __TCHAR_DEFINED +#endif + /* * Use _TEOF instead of EOF or WEOF. It will be appropriately translated if * _UNICODE is correctly defined (or not). @@ -231,11 +241,25 @@ #ifndef _TCHAR_DEFINED #ifndef RC_INVOKED typedef char TCHAR; -typedef char _TCHAR; #endif #define _TCHAR_DEFINED #endif +#ifndef __TCHAR_DEFINED +#ifndef RC_INVOKED +typedef char _TCHAR; +typedef signed char_TSCHAR; +typedef unsigned char _TUCHAR; +#ifdef _MBCS +typedef unsigned char _TXCHAR; +#else +typedef char _TXCHAR; +#endif +typedef int_TINT; +#endif /* Not RC_INVOKED */ +#define __TCHAR_DEFINED +#endif + /* * _TEOF, the constant you should use instead of EOF. */ === Thanks, Dmitry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507522: mingw32-runtime: missing type definitions in tchar.h
Package: mingw32-runtime Version: 3.13-1 Severity: normal Tags: patch The definition of _TSCHAR, _TUCHAR, _TXCHAR, _TINT are missing in tchar.h. The types are normal present in tchar.h shipped by Microsoft and other vendors, so the lack of them makes impossible to use MinGW to compile the source code that rely on these types. The lack of _TUCHAR is the most unfortunate, because the cast to _TUCHAR is often necessary to guarantee that in non-UNICODE case, the argument of character classification routines is inside of the allowed range. For example: _TCHAR *ptr; if (isdigit((_TUCHAR)*ptr)) do_something(); If the cast to _TUCHAR were omitted then in non-UNICODE case (i.e. when TCHAR is char) the argument of isdigit may become negative, which is not allowed by the C standard. I have attached the patch that correct this problem. In this patch, I also moved the definition of _TCHAR inside __TCHAR_DEFINED ifdef block. (If the _TCHAR_DEFINED macro is defined, it means that TCHAR type is defined, while __TCHAR_DEFINED means the same for _TCHAR). Dmitry -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-6-k7 (SMP w/1 CPU core) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash mingw32-runtime depends on no packages. Versions of packages mingw32-runtime recommends: ii mingw32 4.2.1.dfsg-1 Minimalist GNU win32 (cross) compi mingw32-runtime suggests no packages. -- no debconf information --- tchar.h.orig 2007-09-22 23:45:50.0 +0400 +++ tchar.h 2008-12-02 04:33:33.0 +0300 @@ -43,11 +43,21 @@ #ifndef _TCHAR_DEFINED #ifndef RC_INVOKED typedef wchar_t TCHAR; -typedef wchar_t _TCHAR; #endif /* Not RC_INVOKED */ #define _TCHAR_DEFINED #endif +#ifndef __TCHAR_DEFINED +#ifndef RC_INVOKED +typedef wchar_t _TCHAR; +typedef wchar_t _TSCHAR; +typedef wchar_t _TUCHAR; +typedef wchar_t _TXCHAR; +typedef wint_t _TINT; +#endif /* Not RC_INVOKED */ +#define __TCHAR_DEFINED +#endif + /* * Use _TEOF instead of EOF or WEOF. It will be appropriately translated if * _UNICODE is correctly defined (or not). @@ -231,11 +241,21 @@ #ifndef _TCHAR_DEFINED #ifndef RC_INVOKED typedef char TCHAR; -typedef char _TCHAR; #endif #define _TCHAR_DEFINED #endif +#ifndef __TCHAR_DEFINED +#ifndef RC_INVOKED +typedef char _TCHAR; +typedef signed char _TSCHAR; +typedef unsigned char _TUCHAR; +typedef char _TXCHAR; +typedef int _TINT; +#endif /* Not RC_INVOKED */ +#define __TCHAR_DEFINED +#endif + /* * _TEOF, the constant you should use instead of EOF. */
Bug#506723: miro: youtube downloads stopped working
Package: miro Version: 1.2.3-2 Severity: normal Apparently, due to changes in youtube, the download of youtube videos stopped working. This bug is already reported and fixed in upstream. See: http://bugzilla.pculture.org/show_bug.cgi?id=10656 -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-6-k7 (SMP w/1 CPU core) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages miro depends on: ii imagemagick 7:6.3.7.9.dfsg1-2.1+lenny1 image manipulation programs ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libboost-date 1.34.1-14 set of date-time libraries based o ii libboost-file 1.34.1-14 filesystem operations (portable pa ii libboost-pyth 1.34.1-14 Boost.Python Library ii libboost-thre 1.34.1-14 portable C++ multi-threading ii libc6 2.7-16 GNU C Library: Shared libraries ii libcairo2 1.6.4-6.1 The Cairo 2D vector graphics libra ii libgcc1 1:4.3.2-1 GCC support library ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libgtk2.0-0 2.12.11-4 The GTK+ graphical user interface ii libnspr4-0d 4.7.1-4NetScape Portable Runtime Library ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio ii libssl0.9.8 0.9.8g-14 SSL shared libraries ii libstdc++64.3.2-1The GNU Standard C++ Library v3 ii libx11-6 2:1.1.5-2 X11 client-side library ii libxine1 1.1.14-3 the xine video/media player librar ii libxine1-plug 1.1.14-3 the xine video/media player librar ii libxine1-x1.1.14-3 X desktop video output plugins for ii miro-data 1.2.3-2GTK+ based RSS video aggregator da ii python2.5.2-3An interactive high-level object-o ii python-dbus 0.82.4-2 simple interprocess messaging syst ii python-glade2 2.12.1-6 GTK+ bindings: Glade support ii python-gnome2 2.22.0-1 Python bindings for the GNOME desk ii python-gst0.1 0.10.12-1.1generic media-playing framework (P ii python-gtk2 2.12.1-6 Python bindings for the GTK+ widge ii python-gtkmoz 2.19.1-3 Python bindings for the GtkMozEmbe ii python-pysqli 2.4.1-1Python interface to SQLite 3 ii python-suppor 0.8.4 automated rebuilding support for P ii xulrunner-1.9 1.9.0.3-1 XUL + XPCOM application runner ii zlib1g1:1.2.3.3.dfsg-12 compression library - runtime miro recommends no packages. Versions of packages miro suggests: pn python-psyco none (no description available) ii ttf-dejavu2.25-3 Metapackage to pull in ttf-dejavu- -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489961: iceweasel: Iceweasel crash in Gmail chat with pop-out window
Hello Moritz, Installing the security upgrade (Iceweasel 2.0.0.15-0etch1) fixed this problem. So, the bug can be considered closed. Thanks, Dmitry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489961: iceweasel: Iceweasel crash in Gmail chat with pop-out window
Package: iceweasel Version: 2.0.0.14-0etch1 Severity: grave Tags: security Justification: user security hole The following steps are necessary to reproduce this problem: 1. Log-in on your Gmail account 2. Open Gmail chat with any other user 3. Press the pop-out button 4. Close the pop-out window Doing so, you should see Iceweasel (Forefox) crash While it is possible that Google relies on some non-standard feature, the crash itself indicates the secutiry problem inside of Iceweasel. I have tried with Firefox 2.10.15 with the same result. Also, I have heard from a friend of mine that the problem exists with Firefox 2.0 on Windows XP. So, the problem is not Debian specific, yet the problem indicates the present a potential security hold inside of the browser, which should be addressed. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Versions of packages iceweasel depends on: ii debianutils2.17 Miscellaneous utilities specific t ii fontconfig 2.4.2-1.2 generic font configuration library ii libatk1.0-01.12.4-3 The ATK accessibility toolkit ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libcairo2 1.2.4-4.1+etch1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2 generic font configuration library ii libfreetype6 2.2.1-5+etch2 FreeType 2 font engine, shared lib ii libgcc11:4.1.1-21GCC support library ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libgtk2.0-02.8.20-7 The GTK+ graphical user interface ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libmyspell3c2 1:3.1-18 MySpell spellchecking library ii libpango1.0-0 1.14.8-5 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-1PNG library - runtime ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxft22.1.8.2-8 FreeType-based font drawing librar ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxp6 1:1.0.0.xsf1-1X Printing Extension (Xprint) clie ii libxrender11:0.9.1-3 X Rendering Extension client libra ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii psmisc 22.3-1Utilities that use the proc filesy ii zlib1g 1:1.2.3-13compression library - runtime iceweasel recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472615: gitk: impossible to change colors in Edit-Preferences
Package: gitk
Version: 1:1.5.4.4-1
Severity: normal
Attempt to change backround or foreground colors in the Preferences
dialog causes that the invalid color value (with extra curve brackets
around the correct value) is written to ~/.gitk. Also, some other
dialogs stop working immediately after this change. Attempt to restart
gitk again fails until the invalid color value is removed from ~/.gitk.
Steps to reproduce the problem:
1. Go to Edit-Preferences
2. Change the background color a bit.
3. Go to View-New View
gitk reports the following error:
===
unknown color name {#ee}
unknown color name {#ee}
(processing -background option)
invoked from within
entry $top.args -width 50 -textvariable newviewargs($n) -background $bgcolor
(procedure vieweditor line 13)
invoked from within
vieweditor $top $nextviewnum [mc Gitk view definition]
(procedure newview line 14)
invoked from within
newview 0
invoked from within
.#bar.#bar#view invoke active
(uplevel body line 1)
invoked from within
uplevel #0 [list $w invoke active]
(procedure tk::MenuInvoke line 50)
invoked from within
tk::MenuInvoke .#bar.#bar#view 1
(command bound to event)
===
Attempt to restart gitk fails:
===
Error in startup script: unknown color name {#e9}
(processing -background option)
invoked from within
canvas $canv -selectbackground $selectbgcolor -background $bgcolor -bd 0
-yscrollincr $linespc -yscrollcommand scrollcanv $cscroll
(procedure makewindow line 64)
invoked from within
makewindow
(file /usr/bin/gitk line 8632)
===
This error is caused by an incorrect value written by the Preferences
dialog in the ~/.gitk file:
set bgcolor {{#e9}}
It seems the problem is related to using tk8.5 on Debian/Lenny, because
the same gitk does not exhibit this problem with tk8.4.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-6-k7 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages gitk depends on:
ii git-core 1:1.5.4.4-1 fast, scalable, distributed revisi
ii tk8.58.5.1-2 Tk toolkit for Tcl and X11, v8.5 -
gitk recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459470: dblatex depends on opensp for SGML to XML conversion
Package: dblatex Version: 0.2-2 Severity: normal I have tried to use dblatex to convert somedoc.sgml to pdf, so I ran the following command: dblatex -F sgml somedoc.sgml However, it failed with the following error message: Build the XML file... sh: osx: command not found Error: [Errno 2] No such file or directory: 'errors.osx' The cause is that dblatex depends on the opensp package for SGML to XML conversion, but this package is not listed in dblatex dependences. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-k7 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Versions of packages dblatex depends on: ii docbook-xml4.4-5 standard XML documentation system, ii gs-esp [gs-pdfencrypt] 8.15.3.dfsg.1-1 The Ghostscript PostScript interpr ii gs-gpl [gs-pdfencrypt] 8.54.dfsg.1-5 The GPL Ghostscript PostScript int ii python 2.4.4-2 An interactive high-level object-o ii python-support 0.5.6 automated rebuilding support for p ii tetex-extra3.0.dfsg.3-5etch1 Additional TeX input files of teTe ii transfig 1:3.2.5-alpha7-5 Utilities for converting XFig figu ii xsltproc 1.1.19-1 XSLT command line processor dblatex recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459474: dblatex: simplesect tag does not work in appendix
Package: dblatex
Version: 0.2-2
Severity: normal
The following XML file demonstates the problem:
=== BEGIN test.xml ===
?xml version=1.0?
!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN
http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd;
book
chaptertitleChapter title/title
simplesecttitleSimple section in Chapter 1/title
paraSome text goes here./para
/simplesect
/chapter
appendixtitleAppendix title/title
simplesecttitleSimple section in Appendix/title
paraSome text goes here./para
/simplesect
/appendix
/book
=== END test.xml ===
When I run dblatex -t tex test.xml, I get the following warning:
*** section level 6 not well supported
and generated test.tex containts \subparagraph instead of \section
as it is shown below:
% -
% appendixes start here
% -
\appendix
\chapter{appendix title}
\subparagraph{simple section in appendix}
^
it should be \section here.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-k7
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Versions of packages dblatex depends on:
ii docbook-xml4.4-5 standard XML documentation system,
ii gs-esp [gs-pdfencrypt] 8.15.3.dfsg.1-1 The Ghostscript PostScript interpr
ii gs-gpl [gs-pdfencrypt] 8.54.dfsg.1-5 The GPL Ghostscript PostScript int
ii python 2.4.4-2 An interactive high-level object-o
ii python-support 0.5.6 automated rebuilding support for p
ii tetex-extra3.0.dfsg.3-5etch1 Additional TeX input files of teTe
ii transfig 1:3.2.5-alpha7-5 Utilities for converting XFig figu
ii xsltproc 1.1.19-1 XSLT command line processor
dblatex recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429021: builtin echo command redirection misbehaves in detached scripts when terminal is closed
On Sun, Sep 09, 2007 at 10:18:07PM +0100, Stephane Chazelas wrote: Now, I'm not sure if we can say that the new glibc behavior observed is bogus (other than it's different from the behavior observed in all the libcs I tried with). What libc have you tried? To me, the new behavior makes much more sense, as dropping buffer on error is really weird thing to do. I have looked at the source code of newlib and dietlibc, none of them drops buffer on error, and I am not aware about any other implementation of libc that does. It is not a harmless change, for sure as it seems to have broken at least bash, zsh and possibly ksh93. Unfortunately, you are right. I did not foresee that some shells may use dup2(open(file.txt), fileno(stdout)). It is a dirty hack, which may cause some other problems. Frankly, I am a bit surprised that bash uses printf instead of write(2). BTW, you cannot use 'printf' in signal handlers, so it seems that you cannot use 'echo' in trap commands too. Perhaps, we should rollback my patch and give some time for developers to fix their broken shells, but, in this case, what is actually broken are those shells, not libc! Regards, Dmitry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429021: builtin echo command redirection misbehaves in detached scripts when terminal is closed
On Mon, Sep 10, 2007 at 12:05:57AM +0200, Aurelien Jarno wrote: I wouldn't be surprised if it has to do with the fix to debian bug #429021. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429021 (I'm CCing Dmitry who is the author of that change according to bugs.debian.org) I can reproduce the bug with glibc from etch, or even from sarge, so I really doubt that it comes from this change. I can NOT reproduce the problem with glibc from etch, and I do believe that my patch caused the aforementioned problem, though I do not think that the patch was incorrect, as to the real bug lies inside of those shells. Dmitry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429021: builtin echo command redirection misbehaves in detached scripts when terminal is closed
Hi Stephane,
On Mon, Sep 10, 2007 at 09:08:33AM +0100, Stephane Chazelas wrote:
thanks for replying, I gave a list in another email. I tried on
Solaris 7 and HPUX and both seem to flush the buffer upon an
unsuccessful fflush()
I see... I wonder how they work in regard of my original problem
described in the Bug#429021, because it is possible to not discard data
when write failed, but still clean buffer in fflush(). So, functions
like fwrite, printf will not lose some previously written data on error,
but fflush() will always have a clean output buffer at return, so
it will not break existing software, which use dup2 trick.
On the other end, how would you force the flush of the buffer?
The flush means to _deliver_ data, which is impossible in this case.
And how would you redirect stdout? We can use freopen() instead
of the hack above for files, but not for pipes or arbitrary fds
(as in 3).
I see... POSIX has fdopen to create a stream based on the existing
file descriptor, but there is no function to change an existing
stream like 'stdout'. So, I don't know any other portable solution
except avoiding 'stdout'. For some implementations, you can just
assign any FILE pointer to stdout like this:
FILE* out = fdopen(fd, mode);
if (out != NULL)
{
fclose(stdout);
stdout = out;
}
else
report_error();
but in general it does not work, because stdout is rvalue.
Erik Blake was suggesting to use freopen(NULL) (not
to fix that very problem but because of the fact that if you
reassign stdout to some resource of a different nature, you need
to tell stdio as stdio may need to operate differently), but
that's not very portable according to POSIX. Would freopen(NULL)
flush the output buffer?
In Glibc, freopen:
if (filename == NULL _IO_fileno (fp) = 0)
{
fd = __dup (_IO_fileno (fp));
if (fd != -1)
filename = fd_to_filename (fd);
}
Then it closes, the original stream and opens a new one in
the same place. So I believe it should work with glibc
provided you do that you called it after dup2 and that your
system have /proc, because fd_to_filename relies on it.
freopen in newlib does not do anything special about NULL,
so I believe it does not work with NULL.
Perhaps, freopen(/dev/stdout) is a more portable way to
do what you want.
Regards,
Dmitry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429021: builtin echo command redirection misbehaves in detached scripts when terminal is closed
Hello Stephane, I was wrong about suggestion freopen(/dev/stdout) in my previous mail. It cannot be used to redirect stdout. Regards, Dmitry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429021: builtin echo command redirection misbehaves in detached scripts when terminal is closed
On Mon, Sep 10, 2007 at 05:39:09PM +0100, Stephane Chazelas wrote: Dmitry, your t.c in the debian report gives: On Solaris 8: [...] On HPUX 11.11: [...] So they don't seem to care either to retry and send the data if the first write() fails. Yes, it seems they purge all data in the IO buffer on error. With dietlibc: $ ./t signal handler called, sig=2 writer: num_bytes=80008 num_lines=10001 writer: expected num_bytes=8 but was 80008 reader: num_bytes=80007 num_lines=1 reader: number of missing bytes: -7 And dietlibc behaves the same as glibc patched with your (Dmitry's) change upon the fflush. No, glibc with my patch gives: $ ./t signal handler called, sig=2 error at num_bytes=69632 fputs: Interrupted system call writer: num_bytes=8 num_lines=1 reader: num_bytes=8 num_lines=1 -7 indicates an error in dietlibc. Somehow, dietlibc does not take into account that write(2) can write only part of data, and it should not be considered as an error. But this bug in dietlibc is irrelevant to our problem. Newlib should work as glibc with my patch, but I have not tested it. Dmitry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429021: libc6: fputs can lose data in buffer on signal
On Fri, Jun 15, 2007 at 06:47:55PM +0200, Pierre Habouzit wrote:
Nothing in POSIX says what happens wrt to fwrite and signals. At least
it's very unclear. But indeed the fact that SA_RESTART is the default
value for linux does not seem to be a POSIX requirement either.
I have studied the source today, and it turned out that the problem
is not signal specific, but how glibc treats any error on writing.
Unfortunately, it loses all data stored in the buffer. Probably,
it does not matter for fatal errors, because you will not able to
write more anyway, but for recoverable errors like EINTR or ENOSPC,
it is not a smart thing to do. Here is a small patch that corrects
this problem:
--- glibc-2.3.6/libio/fileops.c.orig2004-12-07 01:36:56.0 +0300
+++ glibc-2.3.6/libio/fileops.c 2007-06-18 12:29:50.739890036 +0400
@@ -516,10 +516,19 @@ new_do_write (fp, data, to_do)
fp-_cur_column = INTUSE(_IO_adjust_column) (fp-_cur_column - 1, data,
count) + 1;
_IO_setg (fp, fp-_IO_buf_base, fp-_IO_buf_base, fp-_IO_buf_base);
- fp-_IO_write_base = fp-_IO_write_ptr = fp-_IO_buf_base;
- fp-_IO_write_end = (fp-_mode = 0
+ if (__builtin_expect (count == to_do, 1))
+{
+ fp-_IO_write_base = fp-_IO_write_ptr = fp-_IO_buf_base;
+ fp-_IO_write_end = (fp-_mode = 0
(fp-_flags (_IO_LINE_BUF+_IO_UNBUFFERED))
? fp-_IO_buf_base : fp-_IO_buf_end);
+}
+ else if (count 0 fp-_IO_write_base == data)
+{
+ memmove (data, data+count,
+ fp-_IO_write_ptr - fp-_IO_write_base - count);
+ fp-_IO_write_ptr -= count;
+}
return count;
}
The patch does not change the behavior of new_do_write in the case
of success, but when an error happens, I do not emptify the output
buffer. In fact, in the case when data were partly written (count0)
and data were from the output buffer (fp-_IO_write_base == data),
I remove written data from the buffer and adjust the write pointer
accordingly.
Warning: I have not tested this patch, but it seems trivial, so
I hope it works.
Also, I should note that though this patch prevents losing buffer
on error, it does not prevent the possibility that fputs can return
an error, while a part of the given string was written, but it is
restriction of the interface. So using fputs with non-restartable
signals is not a good idea anyway, still fwrite can be used in
this way for writing bytes if this bug with losing data in buffer
is fixed.
Thanks,
Dmitry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429021: libc6: fputs can lose data in buffer on signal
Package: libc6
Version: 2.3.6.ds1-13
Severity: important
fputs (and probably other FILE based output functions) can lose
previously written data that were accumulated in the user space
buffer when a signal arrives. Here is an example that demonstrates
the problem:
# cat t.c
#include stdio.h
#include signal.h
#include unistd.h
#include string.h
#include errno.h
#include sys/types.h
#include sys/wait.h
#include unistd.h
void handler(int sig)
{
char buffer[80];
snprintf(buffer, sizeof(buffer), signal handler called, sig=%d\n, sig);
write(2, buffer, strlen(buffer));
}
static int main_pid;
#define MYSIGNUM SIGINT
int reader(int fd)
{
char buffer[1024];
ssize_t count;
size_t num_bytes, num_lines;
sleep (1);
kill (main_pid, MYSIGNUM);
sleep (1);
num_bytes = num_lines = 0;
while ((count = read(fd, buffer, sizeof(buffer))) 0)
{
char* p;
for (p=buffer; p!=buffer+count; p++)
if (*p =='\n')
num_lines++;
num_bytes += count;
}
if (count 0)
{
perror (read);
return 1;
}
printf (reader: num_bytes=%d num_lines=%d\n, num_bytes, num_lines);
if (num_bytes != 8*1) {
printf (reader: number of missing bytes: %d\n, 8 - num_bytes);
return 1;
}
close(fd);
return 0;
}
int writer(int fd)
{
int i;
size_t num_bytes, num_lines;
FILE* f = fdopen(fd, w);
if (f == NULL) {
perror (fdopen);
return 1;
}
num_bytes = num_lines = 0;
for (i=0; i10001; i++)
if (fputs (test...\n, f) == EOF)
{
printf (error at num_bytes=%d\n, num_bytes);
perror(fputs);
}
else
{
num_bytes += 8;
num_lines ++;
}
if (fclose(f) == EOF) {
perror(fclose);
return 1;
}
printf (writer: num_bytes=%d num_lines=%d\n, num_bytes, num_lines);
if (num_bytes != 8*1) {
printf (writer: expected num_bytes=8 but was %d\n, num_bytes);
return 1;
}
return 0;
}
int main() {
struct sigaction sa;
int filedes[2];
pid_t pid;
int ret;
main_pid = getpid();
sa.sa_handler = handler;
sigemptyset(sa.sa_mask);
sa.sa_flags = 0;
sigaction(MYSIGNUM, sa, NULL);
if (pipe(filedes))
{
perror(pipe);
return 1;
}
pid=fork();
if (pid == -1)
{
perror(fork);
return 1;
}
if (pid==0)
{
close(filedes[1]);
return reader(filedes[0]);
}
else
{
int status;
close(filedes[0]);
ret = writer(filedes[1]);
wait(status);
return (ret==0 status==0) ? 0 : 1;
}
}
# gcc -W -Wall t.c -o t ./t
signal handler called, sig=2
error at num_bytes=69632
fputs: Interrupted system call
writer: num_bytes=8 num_lines=1
reader: num_bytes=75904 num_lines=9488
reader: number of missing bytes: 4096
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Versions of packages libc6 depends on:
ii tzdata2007b-1Time Zone and Daylight Saving Time
libc6 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421270: gdb: fails to debug multithread programs
Package: gdb Version: 6.6.dfsg-1 Severity: important When I try to debug a multithread application, I get a general error as it is showed below: === ~$gdb ./hello GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu... Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) start Breakpoint 1 at 0x80483a5: file hello.c, line 5. Starting program: /home/dpotapov/hello warning: Lowest section in system-supplied DSO at 0xe000 is .hash at e0b4 [Thread debugging using libthread_db enabled] Error while reading shared library symbols: Cannot find new threads: generic error Cannot find user-level thread for LWP 2518: generic error === I have tried to use both 'stable' and 'unstable' versions of gdb with the same result. I suspect that the problem has something to do with -amd64 kernel (linux-image-2.6-amd64_2.6.18+6_i386.deb), because at the address 0xe000 (which mentioned in the above warning) is the address of linux-gate.so.1, which is a virtual DSO provided by the kernel. === $ldd ./hello linux-gate.so.1 = (0xe000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0xf7ecb000) libc.so.6 = /lib/tls/libc.so.6 (0xf7d99000) /lib/ld-linux.so.2 (0xf7ef4000) === The error happens only when libpthread is linked to the program, but the warning about system-supplied DSO is always showed up. Also if the debug version of libthread_db is used then there is no error, but only the warning. === ~$LD_LIBRARY_PATH=/usr/lib/debug gdb ./hello GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu... Using host libthread_db library /usr/lib/debug/libthread_db.so.1. (gdb) start Breakpoint 1 at 0x80483a5: file hello.c, line 5. Starting program: /home/dpotapov/hello warning: Lowest section in system-supplied DSO at 0xe000 is .hash at e0b4 [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 2542)] [Switching to Thread 16384 (LWP 2542)] main () at hello.c:5 5 printf(Hello world\n); === -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Versions of packages gdb depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libncurses5 5.5-5Shared libraries for terminal hand ii libreadline55.2-2GNU readline and history libraries gdb recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381999: Mono.Runtime -- bug in compile_generic_method
Package: mono-runtime Version: 1.1.13.8-1 Severity: normal Hi! There is a bug that I submitted to Mono bugzilla a few days ago. http://bugzilla.ximian.com/show_bug.cgi?id=79010 The bug is fixed in the current development version now, but I have prepared a patch for the table version (1.1.13.8). See attachment. I hope you will it useful. Thank you, Dmitry fix-compile_generic_method.dpatch Description: Binary data
Bug#356403: wordnet: truncate searching term on a first space
Package: wordnet Version: 2.0g-12 Severity: normal Tags: patch When wnb is started from a command line and the searching term containing any space then it is truncated at the first space symbol, because of a mistake in the wrapper, which uses $@ instead of $@. === begin patch === --- /usr/bin/wnb.orig 2004-04-05 11:01:09.0 +0400 +++ /usr/bin/wnb2006-03-11 23:37:36.337842880 +0300 @@ -34,5 +34,5 @@ export LC_IDENTIFICATION=POSIX export LC_ALL= -/usr/share/wordnet/wnres/wnb $@ +/usr/share/wordnet/wnres/wnb $@ end patch -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.11.6 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Versions of packages wordnet depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libgcc11:3.4.3-13GCC support library ii libstdc++5 1:3.3.5-13The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li ii tcl8.4 8.4.9-1 Tcl (the Tool Command Language) v8 ii tk8.4 8.4.9-1 Tk toolkit for Tcl and X11, v8.4 - ii wordnet-base 2.0g-12 electronic lexical database of Eng ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305951: lpr: fails to start on read-only root
Package: lpr Version: 1:2003.09.23-7S Severity: normal lpd fails to start on a read-only root filesystem system because it cannot create /dev/printer socket. There are two possible ways to fix this bug: 1. To change the default location of the control socket, for example, to /var/run/printer, which is used in NetBSD. 2. Add a new option for lpd that will allow to specify different location for this socket. In this case, anyone who uses a read-only filesystem will able to specify different location for this socket and make /dev/printer as a symbol link to this location. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.11.6 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Versions of packages lpr depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii netbase 4.21 Basic TCP/IP networking system -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
