Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation faults — tracking issue #451

Closed
dmontagu opened this issue Mar 16, 2023 · 26 comments
Closed

Segmentation faults — tracking issue #451

dmontagu opened this issue Mar 16, 2023 · 26 comments
Labels
bug Something isn't working

Comments

@dmontagu
Copy link
Collaborator

I'm creating this issue to track segmentation fault issues that we have run into while working on pydantic or pydantic-core.

Obviously it is a major problem if users are at risk of hitting segmentation faults thanks to using pydantic. So far it seems that when we've hit segmentation faults during development, other potential culprits have been at least tangentially involved, but we should keep an eye out for patterns in case there is anything we can do to minimize the potential for this.

Some cases where we've had segmentation faults:

  • pydantic: MacOS/PyPy 3.9 — note that the segmentation fault is hit very early, potentially before any pydantic_core code has been executed?
  • pydantic-core: CPython3.7 with nightly Rust, and again -- note this appears to have happened after the tests finished running but not before the final testing report was generated
  • Running code in the pycharm debugger — I have frequently had issues where the mere presence of debug points in certain locations in pydantic-internal code has caused a segfault to occur until I moved the debug point/points. (Usually I can get to the line I wanted to break by moving the debug point appropriately and manually stepping, but not always.)

Please add comments on this issue if you run into any new sources of segmentation fault, or discover new patterns in their occurrence, so we can investigate and resolve any issues.

@samuelcolvin
Copy link
Member

PyO3/pyo3#2781 is also relevant.

@samuelcolvin samuelcolvin added the bug Something isn't working label Mar 16, 2023
@samuelcolvin
Copy link
Member

getting this lots more on #465, seems to be happening every time.

@samuelcolvin
Copy link
Member

Okay, I've tried to investigate this, but I'm not finding much.

Steps I took, added

      - uses: mxschmitt/action-tmate@v3
        if: failure()

To ci.yml, then ssh'd into the ci machine and ran the following:

> ls /var/crash
... one file showing "coverage" showd
> pytest
... segfaults again - the problem is not with the python coverage package, but instead with rusts "-C instrument-coverage"
> ls /var/crash
... new file "_opt_hostedtoolcache_Python_3.11.2_x64_bin_pytest.1001.crash" shows
> apport-unpack /var/crash/_opt_hostedtoolcache_Python_3.11.2_x64_bin_pytest.1001.crash  crash-files
> cd crash-files
> ls -lh
total 102M
-rw-r--r-- 1 runner docker    5 Mar 24 11:39 Architecture
-rw-r--r-- 1 runner docker 102M Mar 24 11:39 CoreDump
-rw-r--r-- 1 runner docker   24 Mar 24 11:39 Date
-rw-r--r-- 1 runner docker   12 Mar 24 11:39 DistroRelease
-rw-r--r-- 1 runner docker   49 Mar 24 11:39 ExecutablePath
-rw-r--r-- 1 runner docker   10 Mar 24 11:39 ExecutableTimestamp
-rw-r--r-- 1 runner docker   53 Mar 24 11:39 InterpreterPath
-rw-r--r-- 1 runner docker    5 Mar 24 11:39 ProblemType
-rw-r--r-- 1 runner docker   99 Mar 24 11:39 ProcCmdline
-rw-r--r-- 1 runner docker   45 Mar 24 11:39 ProcCwd
-rw-r--r-- 1 runner docker  113 Mar 24 11:39 ProcEnviron
-rw-r--r-- 1 runner docker  84K Mar 24 11:39 ProcMaps
-rw-r--r-- 1 runner docker 1.4K Mar 24 11:39 ProcStatus
-rw-r--r-- 1 runner docker    2 Mar 24 11:39 Signal
-rw-r--r-- 1 runner docker   30 Mar 24 11:39 Uname
-rw-r--r-- 1 runner docker   19 Mar 24 11:39 UserGroups
> sudo apt install gdb
> gdb CoreDump 
...
> bt
shows something with "??" in it

To try and get symbol information, I changed RUSTFLAGS: '-C instrument-coverage' to RUSTFLAGS: '-C instrument-coverage -g' in ci.yml and ran again.

Again segfault, followed the above, but still no useful information from gdb, here's the output:

> gdb CoreDump 
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
"/home/runner/work/pydantic-core/pydantic-core/crash-files/CoreDump": not in executable format: file format not recognized
(gdb) bt
No stack.
(gdb) list
No symbol table is loaded.  Use the "file" command.
(gdb) file
No executable file now.
No symbol file now.

I really don't know where to go from here - on #465 the coverage run seg faults every time, runs without RUSTFLAGS: '-C instrument-coverage' are always passing. Google is not finding other people with issues like this with instrument-coverage.

@messense @davidhewitt would love your help on this one. Any ideas?

@messense
Copy link
Contributor

messense commented Mar 24, 2023

I just tried but I'm unable to reproduce the segfault with RUSTFLAGS="-g -C instrument-coverage" locally on Ubuntu 22.04 (Python 3.11.2, Rust 1.68.1).

@messense
Copy link
Contributor

While trying to debug with python3.11-dbg, I notice a warning that might be related?

ResourceWarning: Object of type pydantic_core._pydantic_core.SchemaSerializer is not untracked before destruction

@messense
Copy link
Contributor

messense commented Mar 24, 2023

Got a Python traceback after it crashes (but there are no symbols in coredump file)

Fatal Python error: Aborted
Current thread 0x00007f0961223000 (most recent call first):
  File "/root/code/pydantic-core/tests/validators/test_datetime.py", line 185 in test_tz_comparison
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/python.py", line 195 in pytest_pyfunc_call
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 39 in _multicall
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/python.py", line 1789 in runtest
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/runner.py", line 167 in pytest_runtest_call
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 39 in _multicall
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/runner.py", line 260 in <lambda>
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/runner.py", line 339 in from_call
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/runner.py", line 259 in call_runtest_hook
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/runner.py", line 220 in call_and_report
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/runner.py", line 131 in runtestprotocol
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/runner.py", line 112 in pytest_runtest_protocol
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 39 in _multicall
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/main.py", line 349 in pytest_runtestloop
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 39 in _multicall
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/main.py", line 324 in _main
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/main.py", line 270 in wrap_session
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/main.py", line 317 in pytest_cmdline_main
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 39 in _multicall
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/config/__init__.py", line 167 in main
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/_pytest/config/__init__.py", line 190 in console_main
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/pytest/__main__.py", line 5 in <module>
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/coverage/execfile.py", line 211 in run
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/coverage/cmdline.py", line 859 in do_run
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/coverage/cmdline.py", line 682 in command_line
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/coverage/cmdline.py", line 972 in main
  File "/root/code/pydantic-core/.venv/lib/python3.11/site-packages/coverage/__main__.py", line 8 in <module>
  File "/usr/lib/python3.11/runpy.py", line 88 in _run_code
  File "/usr/lib/python3.11/runpy.py", line 198 in _run_module_as_main

Extension modules: black.const, black.mode, black.cache, blib2to3.pgen2.token, blib2to3.pgen2.grammar, blib2to3.pytree, black.strings, blib2to3.pgen2.tokenize, blib2to3.pgen2.parse, blib2to3.pgen2.pgen, blib2to3.pgen2.driver, blib2to3.pygram, black.nodes, black.comments, black.handle_ipynb_magics, black.brackets, black.lines, black.numerics, black.rusty, black.trans, black.linegen, black.parsing, black, pydantic.typing, pydantic.errors, pydantic.version, pydantic.utils, pydantic.class_validators, pydantic.config, pydantic.color, pydantic.datetime_parse, pydantic.validators, pydantic.networks, pydantic.types, pydantic.json, pydantic.error_wrappers, pydantic.fields, pydantic.parse, pydantic.schema, pydantic.main, pydantic.dataclasses, pydantic.annotated_types, pydantic.decorator, pydantic.env_settings, pydantic.tools, pydantic, pydantic._hypothesis_plugin (total: 47)
Aborted (core dumped)

@messense
Copy link
Contributor

Finally got a backtrace in C!

collected 3134 items / 3133 deselected / 1 selected

tests/validators/test_datetime.py
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737350287360) at ./nptl/pthread_kill.c:44
Download failed: Invalid argument.  Continuing without source file ./nptl/./nptl/pthread_kill.c.
44	./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737350287360) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140737350287360) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140737350287360, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff7c97476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff7c7d7f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff7c7d71b in __assert_fail_base (fmt=0x7ffff7e32150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x77bda9 "!_PyErr_Occurred(tstate)", file=0x78fc93 "../Objects/typeobject.c", line=1068, function=<optimized out>)
    at ./assert/assert.c:92
#6  0x00007ffff7c8ee96 in __GI___assert_fail (assertion=assertion@entry=0x77bda9 "!_PyErr_Occurred(tstate)", file=file@entry=0x78fc93 "../Objects/typeobject.c", line=line@entry=1068,
    function=function@entry=0x790510 <__PRETTY_FUNCTION__.30> "type_call") at ./assert/assert.c:101
#7  0x000000000052a1c8 in type_call (type=0xa21640 <_PyExc_ResourceWarning>, args=('Object of type pydantic_core._pydantic_core.SchemaValidator is not untracked before destruction',), kwds=0x0) at ../Objects/typeobject.c:1068
#8  0x00000000004b8b15 in _PyObject_MakeTpCall (tstate=tstate@entry=0xb46058 <_PyRuntime+166328>, callable=callable@entry=<type at remote 0xa21640>, args=args@entry=0x7fffffffbba8, nargs=<optimized out>, keywords=keywords@entry=0x0)
    at ../Objects/call.c:214
#9  0x00000000004b8e91 in _PyObject_VectorcallTstate (tstate=0xb46058 <_PyRuntime+166328>, callable=<type at remote 0xa21640>, args=args@entry=0x7fffffffbba8, nargsf=<optimized out>, nargsf@entry=9223372036854775809,
    kwnames=kwnames@entry=0x0) at ../Include/internal/pycore_call.h:90
#10 0x00000000004b8f4e in PyObject_CallOneArg (func=<optimized out>, arg=<optimized out>) at ../Objects/call.c:376

#11 0x000000000058e1fd in warn_explicit (tstate=0xb46058 <_PyRuntime+166328>, category=<type at remote 0xa21640>,
    category@entry=<error reading variable: Dwarf Error: Cannot find DIE at 0x1c9 referenced from DIE at 0x3de638 [in module /root/code/pydantic-core/pydantic_core/_pydantic_core.cpython-311-x86_64-linux-gnu.so]>,
    message=message@entry='Object of type pydantic_core._pydantic_core.SchemaValidator is not untracked before destruction', filename=filename@entry='gc', lineno=lineno@entry=0, module=module@entry='gc', registry=0x0, sourceline=0x0,
    source=0x0) at ../Python/_warnings.c:671
#12 0x000000000058fe92 in PyErr_WarnExplicitFormat (category=<type at remote 0xa21640>, filename_str=<optimized out>, lineno=0, module_str=<optimized out>, registry=0x0, format=<optimized out>) at ../Python/_warnings.c:1286

@samuelcolvin
Copy link
Member

This is amazing, thank you so much.

Next question - any idea what's actually causing this error? I'm still unclear on how to dig deeper.

Also, I'd love to know what you did to get this traceback.

@messense
Copy link
Contributor

Next question - any idea what's actually causing this error? I'm still unclear on how to dig deeper.

Not sure yet, still digging, that error might not be the root cause of the crash when -C instrument-coverage is on.

Also, I'd love to know what you did to get this traceback.

apt install python3.11-dbg
python3.11-dbg -m venv .venv

sets up a venv with debug build of Python, install pydantic-core and test requirements then run it with gdb

gdb --args .venv/bin/python -m coverage run -m pytest -k test_tz_comparison

@messense
Copy link
Contributor

messense commented Mar 24, 2023

Ahh, now I got a backtrace of LLVM related code crashing with normal Python build

tests/validators/test_datetime.py .                                                                                                                                                                                                 [100%]
Results (2.16s):
         1 passed
      3133 deselected

Program received signal SIGSEGV, Segmentation fault.
WriteBinaryIds (Writer=<optimized out>, Note=0x7ffff179b598, NotesEnd=0x7ffff179b5bc) at ../../src/llvm-project/compiler-rt/lib/profile/InstrProfilingPlatformLinux.c:157
157	../../src/llvm-project/compiler-rt/lib/profile/InstrProfilingPlatformLinux.c: Directory not empty.
(gdb) bt
#0  WriteBinaryIds (Writer=<optimized out>, Note=0x7ffff179b598, NotesEnd=0x7ffff179b5bc) at ../../src/llvm-project/compiler-rt/lib/profile/InstrProfilingPlatformLinux.c:157
#1  __llvm_write_binary_ids (Writer=Writer@entry=0x0) at ../../src/llvm-project/compiler-rt/lib/profile/InstrProfilingPlatformLinux.c:214
#2  0x00007fffef7115c4 in lprofWriteDataImpl (Writer=Writer@entry=0x7fffffffe748, DataBegin=DataBegin@entry=0x7fffef8c3c98, DataEnd=DataEnd@entry=0x7fffef9adc08, CountersBegin=CountersBegin@entry=0x7fffef85c120 "",
    CountersEnd=CountersEnd@entry=0x7fffef8c3c98 "\025\242\247\273\200\273\305uW\036\363\266%\257F\230\210\204\371\377\377\377\377\377", VPDataReader=0x7fffef85c0f0 <TheVPDataReader>,
    NamesBegin=0x7fffef7cbbbe "\207\315-\257\234\003x\332\344]kwڸ\323?\317\067\302\306\030xY\b\355\362os)\311v\273}\243c@\004\247`S\333$\245\237\376\321\305\066\066\330F\266u#{\316n\001\a4\277\031\215F\322hf\004fӻ\327ۻh\034\302\301\323p\277\037\375\357\341/\b\272\301ao\317\367\253\025\f\356\242Q\027\330#\362\336\350\256\374`\353D`\345zn\004\227\223qh\254\237\016\377\373\360c\035\365\"`X", NamesEnd=0x7fffef7f9e66 "", SkipNameDataWrite=0)
    at ../../src/llvm-project/compiler-rt/include/profile/InstrProfData.inc:130
#3  0x00007fffef71148c in lprofWriteData (Writer=Writer@entry=0x7fffffffe748, VPDataReader=<optimized out>, SkipNameDataWrite=<optimized out>, SkipNameDataWrite@entry=0)
    at ../../src/llvm-project/compiler-rt/lib/profile/InstrProfilingWriter.c:251
#4  0x00007fffef70f6a9 in writeFile (OutputName=OutputName@entry=0x7fffffffe790 "default_8652830865286370462_0_1423815.profraw") at ../../src/llvm-project/compiler-rt/lib/profile/InstrProfilingFile.c:480
#5  0x00007fffef70f422 in __llvm_profile_write_file () at ../../src/llvm-project/compiler-rt/lib/profile/InstrProfilingFile.c:1051
#6  0x00007ffff7c9a495 in __run_exit_handlers (status=0, listp=0x7ffff7e6e838 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:113
#7  0x00007ffff7c9a610 in __GI_exit (status=<optimized out>) at ./stdlib/exit.c:143
#8  0x00007ffff7c7ed97 in __libc_start_call_main (main=main@entry=0x5feeb0 <main>, argc=argc@entry=8, argv=argv@entry=0x7fffffffe978) at ../sysdeps/nptl/libc_start_call_main.h:74
#9  0x00007ffff7c7ee40 in __libc_start_main_impl (main=0x5feeb0 <main>, argc=8, argv=0x7fffffffe978, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe968) at ../csu/libc-start.c:392
#10 0x00000000005fede5 in _start ()

I think this might indicate that the crash is caused by LLVM failed to write out the .profraw file.

https://github.com/rust-lang/llvm-project/blob/fd949f3034f8a422ecfffa889c2823485dde4bdd/compiler-rt/lib/profile/InstrProfilingPlatformLinux.c#L157

@samuelcolvin
Copy link
Member

Great, very good to know this really does relate to writing coverage files.

Any idea why the test_tz_comparison test in particular is causing this?

Also really weird that it's started happening every time on #465 although that PR doesn't touch or test any of that code.

@messense
Copy link
Contributor

Any idea why the test_tz_comparison test in particular is causing this?

No idea yet, maybe fix the ResourceWarning will help?

@samuelcolvin
Copy link
Member

Turns out this is not just a 3.11 thing, see #473 and this ci run.

@messense
Copy link
Contributor

Reported the ResourceWarning to pyo3: PyO3/pyo3#3064

@samuelcolvin
Copy link
Member

Thanks, I did a bit of digging and the resource warning happens everywhere, so I don't think that's the cause of the seg fault.

@samuelcolvin
Copy link
Member

samuelcolvin commented Mar 27, 2023

Further digging, I tried:

  • removing the no_coverage tags
  • using rust stable (we were using nightly to support the no_coverage tags)

In both cases we still get the seg fault 😞.

See #477.

@messense
Copy link
Contributor

messense commented Mar 27, 2023

Since the segfault happens in LLVM, IMO it's better to debug it with a debug build of Rust and report to Rust or LLVM project. Though it might be hard to narrow it down to a minimal repro.

@samuelcolvin
Copy link
Member

Honestly, I've tried pretty hard to reproduce this locally, but can't.

How did you get the seg fault to happen locally?

@messense
Copy link
Contributor

messense commented Mar 27, 2023

I'm simply using a normal Python 3.11 with the following commands running at the root of the project.

ulimit -c unlimited
python3.11 -m venv .venv
.venv/bin/pip install -r tests/requirements.txt
RUSTFLAGS="-g -C instrument-coverage" maturin develop --release
gdb --args .venv/bin/python -m coverage run -m pytest -k test_tz_comparison

and run in gdb.

@messense
Copy link
Contributor

BTW, remove strip = true in here before running maturin develop:

strip = true

@samuelcolvin
Copy link
Member

I'm afraid I still can't reproduce the failure locally on either macos or ubuntu.

@samuelcolvin
Copy link
Member

so turns out we don't get the seg fault on either macos or ubuntu-20.04, so I've switched to 20.04 for coverage for now as I don't have time to debug this further.

@dmontagu
Copy link
Collaborator Author

Haven't had this issue in forever so I'm going to close this now.

@SrGitQ
Copy link

SrGitQ commented Jan 18, 2024

I recreate this issue with Ubuntu 22, Windows/WSL and Docker ubuntu:latest by creating a python-module called datetime (folder with init | python file)...

Python==3.12 | 3.11 | 3.10
pydantic==2.5.2
pydantic_core==2.14.5

Commands and returns without datetime module

(venv) » tree -I '__pycache__' utils       
utils
├── config.py
└── date
    └── __init__.py

1 directory, 2 files

(venv) » more utils/date/__init__.py

(venv) » more utils/config.py
from pydantic import BaseModel

(venv) » python3 utils/config.py 
(no errors, import successfull)

After renaming the folder date to datetime:

(venv) » tree -I '__pycache__' utils 
utils
├── config.py
└── datetime
    └── __init__.py

1 directory, 2 files
(venv) » python3 utils/config.py
[1]    7836 segmentation fault (core dumped)  python3 utils/config.py

Return from faulthandler enabled:

Fatal Python error: Segmentation fault

Current thread 0x00007f0488364000 (most recent call first):
  File "<frozen importlib._bootstrap>", line 241 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 1176 in create_module
  File "<frozen importlib._bootstrap>", line 571 in module_from_spec
  File "<frozen importlib._bootstrap>", line 674 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1006 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1027 in _find_and_load
  File "/venv/lib/python3.10/site-packages/pydantic_core/__init__.py", line 6 in <module>
  File "<frozen importlib._bootstrap>", line 241 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 883 in exec_module
  File "<frozen importlib._bootstrap>", line 688 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1006 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1027 in _find_and_load
  File "/venv/lib/python3.10/site-packages/pydantic/main.py", line 11 in <module>
  File "<frozen importlib._bootstrap>", line 241 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 883 in exec_module
  File "<frozen importlib._bootstrap>", line 688 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1006 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1027 in _find_and_load
  File "<frozen importlib._bootstrap>", line 1050 in _gcd_import
  File "/usr/lib/python3.10/importlib/__init__.py", line 126 in import_module
  File "/venv/lib/python3.10/site-packages/pydantic/__init__.py", line 372 in __getattr__
  File "<frozen importlib._bootstrap>", line 1075 in _handle_fromlist
  File "/src/utils/config.py", line 3 in <module>
[1]    7878 segmentation fault (core dumped)  python3 utils/config.py

@davidhewitt
Copy link
Contributor

@SrGitQ can you please open that as a new issue with a full repro of instructions how to observe this (including the source code)? I would be happy to investigate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants