El hilo del laberinto (Publicaciones sobre Depuración)

Python 3.13: zlib.error: Error -2 while flushing: inconsistent stream state

Jesús Cea Avión — Sun, 29 Dec 2024 09:32:00 GMT

Tras actualizar a Python 3.13 y mod_wsgi, tal y como se describe en Problema actualizando mis servicios WSGI a Python 3.13, empecé a ver estos errores en el log:

Exception ignored in: <gzip on 0x7fd58e3c6fb0>
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/gzip.py", line 373, in close
    fileobj.write(self.compress.flush())
zlib.error: Error -2 while flushing: inconsistent stream state

La excepción no parece tener ningún efecto práctico en el programa, pero muestra que hay un problema a resolver.

Lo primero que llama la atención es que el traceback no parece completo, no indica qué código está llamando a la función close(). Ese detalle junto al mensaje Exception ignored in: indica que se trata de una excepción asíncrona que ocurre en un destructor.

Para saber qué parte del código está generando esa excepción (de forma asíncrona), podemos modificar el código añadiendo esto al principio:

 import sys, inspect
 class GzipFile(gzip.GzipFile):
     def __init__(self, *args, **kwargs):
         creador = inspect.stack()[1]
         self._creador = (creador.filename, creador.function, creador.lineno)
         del creador
         return super().__init__(*args, **kwargs)

     def close(self):
         try:
             print("CLOSE", file=sys.stderr)
             return super().close()
         except Exception as exc:
             print(self._creador, file=sys.stderr)
             raise

 gzip.GzipFile = GzipFile

Leer más… (quedan 6 minutos de lectura)

Problema actualizando mis servicios WSGI a Python 3.13

Jesús Cea Avión — Sat, 12 Oct 2024 00:00:00 GMT

Acaba de salir Python 3.13 y, como siempre, actualizo mi código y servicios a esta nueva versión. Actualizo rápido para aprovechar las mejoras de la nueva versión de Python y porque acumular actualizaciones pendientes supone que el coste de migrar va creciendo cada año.

Normalmente los cambios necesarios son mínimos, pero en esta ocasión tengo problemas con mis servicios WSGI a través del módulo mod_wsgi.

Los servicios en sí parecen funcionar correctamente, pero los logs se saturan de cientos de líneas por segundo con el siguiente error:

Exception ignored in: <_io.TextIOWrapper name='<wsgi.errors>' encoding='utf-8'>
RuntimeError: log object has expired

Viendo el código fuente de mod_wsgi y del propio intérprete de Python, esto ocurre cuando se escribe en el log (o se hace flush) una vez que ya se ha llamado a close. La parte de Exception ignored está dentro del intérprete de Python, cuando se intenta escribir en un fichero que no puede dar una excepción. Por ejemplo, cuando un destructor levanta una excepción o durante la recogida de basuras.

Aunque todo parece ir bien, de momento seguiré con Python 3.12, mientras investigo el problema en detalle. Ahora mismo estoy bastante ocupado...

20241015: Alguien se me ha adelantado informando del problema: RuntimeError: log object has expired in mod_wsgi 5.0.1 with Django 5.0.9 python 3.13.0 #912.

20241122: Se publica la versión 5.0.2 de mod_wsgi que, aparentemente, soluciona este problema.

20250125: Encuentro un rato para actualizar mis servicios WSGI a la nueva versión de mod_wsgi y confirmo que el problema se ha solucionado.

SmartOS: Stock "mkvtoolnix" crashes on 2023.4.0 with locale error

Jesús Cea Avión — Tue, 13 Aug 2024 21:57:00 GMT

This post transcribes some emails I sent to the SmartOS mailing list some time ago. You can check the original thread:

Message-ID: <15dec164-940e-17d7-a7db-dcdf19f9ec2d@jcea.es>
Date: Tue, 12 Mar 2024 14:07:13 +0100
To: smartos-discuss <smartos-discuss@lists.smartos.org>
From: Jesus Cea <jcea@jcea.es>
List-Id: "smartos-discuss" <smartos-discuss.lists.smartos.org>
Subject: [smartos-discuss] Stock "mkvtoolnix" crashes on 2023.4.0 with locale
  error

Hi, there.

I install "pkgin install mkvtoolnix" with no issues (but a huge number
of dependencies, 1.6 Gigabytes total!).

Then, I run "mkvmerge" and it crashes:

"""
[jcea@test ~]$ mkvmerge
terminate called after throwing an instance of 'std::runtime_error'
what():  locale::facet::_S_create_c_locale name not valid
Abort (core dumped)
"""

This worked fine in 2022.4.0.

My environment variables are:

"""
MANPATH=/opt/local/man:/usr/share/man:/opt/local/lib/perl5/man:/opt/local/lib/perl5/vendor_perl/man
LC_MONETARY=es_ES.UTF-8
TERM=xterm
SHELL=/usr/bin/bash
SSH_CLIENT=***
LC_NUMERIC=es_ES.UTF-8
SSH_TTY=/dev/pts/26
USER=root
COLUMNS=80
PAGER=less
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/opt/local/sbin:/opt/local/bin:/usr/sbin:/usr/bin:/sbin
LC_COLLATE=es_ES.UTF-8
PWD=/home/jcea
LANG=en_US.UTF-8
TZ=Europe/Madrid
LINES=25
SHLVL=1
HOME=/home/jcea
TERMINFO=/opt/local/share/lib/terminfo
LOGNAME=jcea
SSH_CONNECTION=****
LC_TIME=es_ES.UTF-8
FTPMODE=auto
_=/opt/local/bin/env
"""

Jonathan Perkin replied:

Leer más… (quedan 11 minutos de lectura)

Los peligros de volcar a "pickle" cualquier cosa

Jesús Cea Avión — Tue, 16 Apr 2024 20:46:00 GMT

En Generar un email diario a partir de un feed RSS (Slashdot) y Mejoras a la hora de generar un email diario a partir de un feed RSS (Slashdot) describo un programa para enviar por email las novedades diarias de un feed RSS.

Aunque al programa le vendría bien una reescritura, todo fue bien hasta hace unos días, cuando el programa falló con un error indicando que no se podía recuperar el estado volcado con pickle debido a una dependencia (inesperada e inadvertida) con beautifulsoup4.

El error en sí era críptico y poco claro, pero ocurrió tras haber actualizado la biblioteca beautifulsoup4. Esto fue una pista crucial. Obviamente todo volvió a la normalidad tras instalar una versión previa y así siguió cumpliendo con su trabajo unos días hasta que encontré tiempo para echarle un vistazo. La actualización de beautifulsoup4 no era urgente y pude aplazar la investigación hasta que me vino bien.

Una vez metido en faena quedó claro que el problema era que la estructura interna de beautifulsoup4 había cambiado y los objetos serializados de la versión anterior de beautifulsoup4 no podían cargarse en la versión actual de la biblioteca. Esto no es ninguna sorpresa, es lo normal. La sorpresa es que estuviera serializando objetos beautifulsoup4 de forma inadvertida.

Leer más… (quedan 2 minutos de lectura)

SmartOS: Serious issue with openjdk 17 and TLS

Jesús Cea Avión — Sun, 31 Dec 2023 15:34:00 GMT

This post transcribes some emails I sent to several mailing lists:

The initial email was sent to the Kafka User mailing list:

Reply-To: users@kafka.apache.org
Message-ID: <92aa6286-d875-04ed-6205-9e4a8fe3a1a1@jcea.es>
Date: Thu, 9 Nov 2023 03:37:39 +0100
To: users@kafka.apache.org
From: Jesus Cea <jcea@jcea.es>
Subject: How to get a X509 broker certificate with "openssl s_client"?

I am trying to remotely access to the brokers certificates (for audit
purposes, expiration alarms, etc) using this command:

"""
openssl s_client -showcerts -connect localhost:9092
"""

The connection is correctly established, but something is wrong. The TLS
session is has some errors at the beginning, but it success at the end:

"""
[jcea@Kafka ~]$ openssl s_client -showcerts -connect localhost:9092
CONNECTED(00000004)
1:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad
record mac:ssl/record/ssl3_record.c:676:
---
no peer certificate available
---
No client certificate CA names sent
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1696 bytes and written 300 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
"""

I tried too writing a tiny TLS client in Python, same result, raising
this exception: "ssl.SSLError: [SSL:
DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac
(_ssl.c:992)".

I guess there is some kind of preamble before TLS negotiation.

Is that documented somewhere?. How can I check remotely the brokers'
certificates?

Thanks.

Leer más… (quedan 6 minutos de lectura)

Cómo saber el tamaño de una función en Código Objeto

Jesús Cea Avión — Sat, 31 Dec 2022 19:45:00 GMT

Por motivos complicados necesitaba conocer el tamaño de una función en C, una vez compilada a código objeto. A priori no hay forma simple de saberlo.

Acabé volcando el listado de funciones y sus direcciones a partir del código objeto, ordenando las funciones por su dirección, buscando la dirección de la función que me interesa y buscando la dirección de la función que la sigue. Restando ambas obtenía el tamaño de la función.

Años más tarde volví a revisar el tema. Lo que me molestaba era lo que sigue:

Tomemos el siguiente código C:

1
2
3

 int a(int x) {
     return 2*x;
 }

Si compilamos el código anterior y generamos código fuente en ensamblador de x86 con gcc -S -O9 a.c, vemos lo siguiente:

         .file   "a.c"
         .text
         .p2align 4
         .globl  a
         .type   a, @function
 a:
 .LFB0:
         .cfi_startproc
         endbr64
         leal    (%rdi,%rdi), %eax
         ret
         .cfi_endproc
 .LFE0:
         .size   a, .-a
         .ident  "GCC: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0"
         .section        .note.GNU-stack,"",@progbits
         .section        .note.gnu.property,"a"
         .align 8
         .long    1f - 0f
         .long    4f - 1f
         .long    5
 0:
         .string  "GNU"
 1:
         .align 8
         .long    0xc0000002
         .long    3f - 2f
 2:
         .long    0x3
 3:
         .align 8
 4:

La clave del asunto es la línea 14: .size a, .-a. Según el manual de gas, eso guarda como tamaño de la función a la resta entre la posición actual del ensamblador y la primera instrucción de a. Es decir, resta a la dirección final de la función la dirección inicial. Es decir, obtenemos el tamaño.

Aparentemente, entonces, se está generando esa información y se guarda en el código objeto. ¿Cómo acceder a ella?

Leer más… (quedan 1 minutos de lectura)