unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#69064: python-mysqlclient: MySQLdb.string_literal SIGSEGV
@ 2024-02-12  0:08 Marco Rimoldi
       [not found] ` <handler.69064.B.170769653911763.ack@debbugs.gnu.org>
  0 siblings, 1 reply; 2+ messages in thread
From: Marco Rimoldi @ 2024-02-12  0:08 UTC (permalink / raw)
  To: 69064

Hello,

I think I found a bug in python-mysqlclient@2.0.1 compiled with mariadb:dev@10.10.2.

To reproduce: run a Python 3.10.7 terminal, import the MySQLdb module, call the  string_literal function with any argument. Interpreter crashes due to segmentation fault. Arch is x86_64.

Same with version 2.2.4, tested tweaking the package definition.

I tried installing mariadb with debug symbols, but I was not able to make mysqlclient link against that variant (either using transformations in a manifest file or --with-debug-info=mariadb). Suggestions are welcome.

The bug affects the openmolar package.

Marco




^ permalink raw reply	[flat|nested] 2+ messages in thread

* bug#69064: python-mysqlclient: MySQLdb.string_literal SIGSEGV
       [not found] ` <handler.69064.B.170769653911763.ack@debbugs.gnu.org>
@ 2024-02-12 14:19   ` Marco Rimoldi
  0 siblings, 0 replies; 2+ messages in thread
From: Marco Rimoldi @ 2024-02-12 14:19 UTC (permalink / raw)
  To: 69064

I've set up to test this bug with a more recent version of mariadb, but I must be missing something important about the Guix workflow here. Maybe that could explain the bug as an error on my part, as well. I'd really appreciate your help, because I'm at a loss here.

The steps I've taken so far:

I populated a manifest.scm file along these lines:

(define-public mariadb-test
  (package
    (name "mariadb-test")
    (version "10.11.7")
    [...]
    (build-system cmake-build-system)
    (outputs '("out" "lib" "dev"))
    (arguments
     `(#:tests? #f   ;; tests disabled but passing for the most part
    [...]

(define-public python-mysqlclient-test
  (package
    (name "python-mysqlclient")
    (version "2.2.4")
    [...]
    (build-system pyproject-build-system)
    (arguments '(#:tests? #f))          ;XXX: requires a live database
    (inputs (list pkg-config 
                  `(,mariadb-test "dev")
		  `(,mariadb-test "lib")
                  zlib))
    (propagated-inputs (list `(,mariadb-test "lib")))
    [...]

(define transform
  (options->transformation
   '((with-debug-info . "mariadb-test"))))

(packages->manifest (list gdb
			  python-pdbpp
			  python-3
			  (transform python-mysqlclient-test)
			  (transform mariadb-test)))

I then launched a guix shell and ran the debugger:

guix shell --manifest=manifest.scm
gdb --args "python3 test.py"
(gdb) run
Starting program: /gnu/store/hm1kl7zi0r2nbg1zgh8ywwm0h35h6zfx-profile/bin/python3 test.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff75b5f23 in ?? () from /gnu/store/z0c58i28g97z85w986i841l4crbpf8zk-mariadb-10.10.2-lib/lib/libmariadb.so.3

The part that I cannot understand is why the segfault always happens in mariadb-10.10.2-lib, ie. a different package compared to what I declared in the manifest file. This happens after running "guix gc", as well.

Marco




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-02-12 14:41 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-12  0:08 bug#69064: python-mysqlclient: MySQLdb.string_literal SIGSEGV Marco Rimoldi
     [not found] ` <handler.69064.B.170769653911763.ack@debbugs.gnu.org>
2024-02-12 14:19   ` Marco Rimoldi

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).