Bug#1009710: minor memory leaks
The previous report was done after noticing a lot more of problems when using the stack glfw3 + glm + epoxy + mesa with intel drivers. Valgrind reports lot of memory problems notably when using glCompileShader, when loading shared libraries (dlopen) and many more. I can provide the source code that I'm writing which triggers those, it's intended to be FOSS in any case, but it's very young and does nothing interesting (taking my time to write code with every possible error checking in the graphical stack). I have not reported those information is original bug report, because they do not belong directly to glfw3. Sending multiple reports would be an option, but I'm not sure it's very productive, especially if this is going to be ignored (problems are only seen with valgrind AFAIK and some of those might be related to stuff I did in my code, notably the shaders. I need to dig more to be confident enough there to send a report.)
Bug#1009710: libglfw3: valgrind finds memory leak
Package: libglfw3
Version: 3.3.2-1
Severity: minor
Tags: upstream
X-Debbugs-Cc: berengermore...@gmail.com
When writting a minimal C program with glfw3, valgrind find leaked
memory.
Code of the program:
```
#include
int main()
{
glfwInit();
glfwTerminate();
}
```
Compiling and running with:
```
clang test.c $(pkg-config --libs glfw3)
valgrind --leak-check=full --show-leak-kinds=all --log-file=log ./a.out
```
will generate the report showing the leaks. You will need to install
several dbgsym packages to see the whole stacks, though.
-- System Information:
Debian Release: 11.3
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
Versions of packages libglfw3 depends on:
ii libc6 2.31-13+deb11u3
ii libgl11.3.2-1
ii libx11-6 2:1.7.2-1
libglfw3 recommends no packages.
Versions of packages libglfw3 suggests:
ii libegl1 1.3.2-1
ii libgles11.3.2-1
ii libgles21.3.2-1
ii libosmesa6 20.3.5-1
ii libvulkan1 1.2.162.0-1
-- no debconf information
Bug#980764: libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed()
Le Fri, 22 Jan 2021 23:45:45 +0100, Florian Weimer a écrit : Hello. Sorry for the delay, I completely forgot about this issue. > * Bérenger: ... > Why do you think this is a bug? POSIX 10031-2017 standard says: > RETURN VALUE Upon successful completion, the dprintf( ), fprintf( ), and printf( ) functions shall return the number of bytes transmitted. Upon successful completion, the sprintf( ) function shall return the number of bytes written to s, excluding the terminating null byte. > Upon successful completion, the snprintf( ) function shall return the number of bytes that would be written to s had n been sufficiently large excluding the terminating null byte. > If the value of n is zero on a call to snprintf( ), nothing shall be written, the number of bytes that would have been written had n been sufficiently large excluding the terminating null shall be returned, and s may be a null pointer. I changed my code so that it stores printf's result. It does not contains 0, which is the real number of bytes transmitted (none were), but the number of bytes it should have transmitted. In the error section, we can read that it can return the same errors (in errno) as fputc, which itself says, as for errors: > [EBADF] The file descriptor underlying stream is not a valid file > descriptor open for writing. This is clearly the case here. The underlying file descriptor *is* closed. Thus, fputc (thus fprintf) functions should return -1 and have errno set at EBADF. I do not have access to older versions of POSIX nor to C standard. According to wikipedia, "Debian 10 (Buster) was released on 6 July 2019;" which is at least 1 year after the POSIX standard I put a reference to was out. I must confess I didn't checked the POSIX standard on this question before writting this answer, because the manpage clearly states that "Upon successful return, these functions return the number of characters printed" which is not the case here. I do note that the manpage does not mentions errors returned nor being conform to POSIX-2017: it says: > CONFORMING TO fprintf(), printf(), sprintf(), vprintf(), vfprintf(), vsprintf(): POSIX.1-2001, POSIX.1-2008, C89, C99. > snprintf(), vsnprintf(): POSIX.1-2001, POSIX.1-2008, C99. With those informations, I really think this is a glibc bug (not present in muslc since it do returns -1 and sets errno at -9, which is the defined value of EBADF). PS: sorry for putting you in "To" field, Florian Weimer, did a "reply", instead of "reply to all"
Bug#980764: libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed()
Package: libc6-dev
Version: 2.28-10
Severity: normal
When running following code:
```C
#include
#include
#include
int main()
{
close( STDIN_FILENO );
close( STDOUT_FILENO );
int fd = dup( STDERR_FILENO );
close( STDERR_FILENO );
if( -1 == fprintf( stdout, "%d\n", fd ) )
{
return -1;
}
char s[] = "should fail\n";
if( -1 == write( STDOUT_FILENO, s, sizeof( s ) ) )
{
return -2;
}
return EXIT_SUCCESS;
}
```
built with glibc, the program returns 254. When built with muslc, it
returns the expected value of 255.
I believe glibc's behavior here is wrong. From what I could get by using
strace, it seems that the 1st printf's write() call is ran _after_ the
2nd one, even when adding a call to fflush( stdout ) right after the
printf.
A way to make the code behaving as one would expect is to add a fprintf
call before closing descriptor. It then behaves as expected with both
libCs.
-- System Information:
Debian Release: 10.7
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
Versions of packages libc6-dev depends on:
ii libc-dev-bin2.28-10
ii libc6 2.28-10
ii linux-libc-dev 4.19.160-2
libc6-dev recommends no packages.
Versions of packages libc6-dev suggests:
pn glibc-doc
ii manpages-dev 4.16-2
-- no debconf information
Bug#733480: bash: 4.3~rc2 is also very slow
Le Mer 26 février 2014 22:21, Matthias Klose a écrit : > Am 26.02.2014 22:06, schrieb Morel Bérenger: > >> Le Mer 26 février 2014 21:59, Matthias Klose a écrit : >> >>> Am 26.02.2014 21:56, schrieb Bérenger: >>> >>> >>>> Package: bash >>>> Version: 4.3~rc2-1 >>>> Followup-For: Bug #733480 >>>> >>>> >>>> >>>> Dear Maintainer, >>>> >>>> >>>> >>>> I did not tried bash 4.3~rc1, but I recently tried the rc2, and >>>> it's very slow, making my system almost unusable since I use >>>> terminals to do almost everything on my computer. >>> >>> debug options are enabled in this build. So please bear with it and >>> continue testing. >>> >>> thanks, Matthias >>> >>> >>> >> >> I can not. I would really like to help with testing, but more than 20s >> to start a new terminal, and more than 5s each time I try to auto >> complete, on a system where there terminals are used as file browser, >> makes the system almost unusable. But at least now I know why it's slow, >> thanks for the infomation. Obviously, with debug infos, it can't be fast >> ( but still, I'm surprised >> to have it as slow ). > > apt-get remove bash-completion I should have thought about it sooner. Removing it seems to have fixed the performance problem even at bash's startup. Now, I do not remember exactly why I installed it, but I think I did it for a reason ( recommended packages are not automatically installed on my computer ). Let's see how long I can stop using it and stay productive :) PS: I was not able to find bash's changelog between version 4.2 and 4.3. Have some hint about where to locate it? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733480: bash: 4.3~rc2 is also very slow
Le Mer 26 février 2014 21:59, Matthias Klose a écrit : > Am 26.02.2014 21:56, schrieb Bérenger: > >> Package: bash >> Version: 4.3~rc2-1 >> Followup-For: Bug #733480 >> >> >> Dear Maintainer, >> >> >> I did not tried bash 4.3~rc1, but I recently tried the rc2, and it's >> very slow, making my system almost unusable since I use terminals to do >> almost everything on my computer. > > debug options are enabled in this build. So please bear with it and > continue testing. > > thanks, Matthias > > > I can not. I would really like to help with testing, but more than 20s to start a new terminal, and more than 5s each time I try to auto complete, on a system where there terminals are used as file browser, makes the system almost unusable. But at least now I know why it's slow, thanks for the infomation. Obviously, with debug infos, it can't be fast ( but still, I'm surprised to have it as slow ). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733480: bash: 4.3~rc2 is also very slow
Package: bash
Version: 4.3~rc2-1
Followup-For: Bug #733480
Dear Maintainer,
I did not tried bash 4.3~rc1, but I recently tried the rc2, and it's very slow,
making my system almost unusable since I use terminals to do almost everything
on my computer.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages bash depends on:
ii base-files 7.2
ii dash 0.5.7-4
ii debianutils 4.4
ii libc62.18-0experimental1
ii libtinfo55.9+20140118-1
Versions of packages bash recommends:
ii bash-completion 1:2.1-2
Versions of packages bash suggests:
pn bash-doc
-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
if [ -x /usr/lib/command-not-found -o -x
/usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/bin/python /usr/lib/command-not-found -- "$1"
return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
/usr/bin/python
/usr/share/command-not-found/command-not-found -- "$1"
return $?
else
printf "%s: command not found\n" "$1" >&2
return 127
fi
}
fi
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
case "$TERM" in
xterm-color) color_prompt=yes;;
esac
force_color_prompt=yes
if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
'
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
