Bug#968825: mono-runtime: NullReferenceException in System.Linq.Enumerable.ToArray

2020-08-21 Thread Dmitry Potapov
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

2010-03-07 Thread Dmitry Potapov
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

2008-12-02 Thread Dmitry Potapov
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

2008-12-01 Thread Dmitry Potapov
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

2008-11-23 Thread Dmitry Potapov
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   (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

2008-07-11 Thread Dmitry Potapov
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

2008-07-08 Thread Dmitry Potapov
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

2008-03-25 Thread Dmitry Potapov
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#459474: dblatex: simplesect tag does not work in appendix

2008-01-06 Thread Dmitry Potapov
Package: dblatex
Version: 0.2-2
Severity: normal


The following XML file demonstates the problem:

=== BEGIN test.xml ===

http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd";>


  Chapter title
Simple section in Chapter 1
  Some text goes here.

  
  Appendix title
Simple section in Appendix
  Some text goes here.

  

=== 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#459470: dblatex depends on opensp for SGML to XML conversion

2008-01-06 Thread Dmitry Potapov
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#429021: builtin echo command redirection misbehaves in detached scripts when terminal is closed

2007-09-10 Thread Dmitry Potapov
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: builtin echo command redirection misbehaves in detached scripts when terminal is closed

2007-09-10 Thread Dmitry Potapov
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

2007-09-10 Thread Dmitry Potapov
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

2007-09-10 Thread Dmitry Potapov
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

2007-09-10 Thread Dmitry Potapov
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: libc6: fputs can lose data in buffer on signal

2007-06-18 Thread Dmitry Potapov
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 (count>0)
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

2007-06-15 Thread Dmitry Potapov
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 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


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; i<10001; 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

2007-04-27 Thread Dmitry Potapov
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

2006-08-08 Thread Dmitry Potapov

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

2006-03-11 Thread Dmitry Potapov
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

2005-04-22 Thread Dmitry Potapov
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]