Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
Thanks a lot for this really quick fix Dima. I gave it positive review already. On Friday, April 12, 2024 at 4:27:31 PM UTC+3 Georgi Guninski wrote: My results differ. If you want more systematic approach for QA and security (the recent paranoia induced by the xz backdoor) you will need moderate budget possibly with zero trust to me. Georgi, I don't understand what you are trying to say here exactly. I guess with "my results differ" you mean that the crash happens in different places? But why should we have "zero trust" in you? julian -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ffcff9f1-6ed5-48a3-9030-ce10ceb8ebd8n%40googlegroups.com.
Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
My results differ. If you want more systematic approach for QA and security (the recent paranoia induced by the xz backdoor) you will need moderate budget possibly with zero trust to me. Have a nice weekend. On Fri, Apr 12, 2024 at 3:52 PM Dima Pasechnik wrote: > > > > On 12 April 2024 12:42:39 CEST, Georgi Guninski wrote: > >On Fri, Apr 12, 2024 at 11:35 AM Dima Pasechnik wrote: > >> > >> This should be fixed by https://github.com/sagemath/sage/pull/37792 > >> please review > >> > > > >I suspect reproducing is hard, since it depends on the time of pressing > >CTL-C. > > Well, in all my tries the crash happened in the same place, the place that > now is no longer reachable. > > And the reason for the crash was, AFAIU, due to calling a plain Python code > (where Ctrl-C was caught) from a "noexcept" Cython code. That is, it's a > crash due to inability to properly process Ctrl-C. > > How many more similar places are left there in Cython code in Sage, I don't > know. > > Dima > > > >Also, lack a crash may be silent memory corruption. > > > >It is weird that the crash is not always. > > > >Do you fix the attached new testcase (no interaction required, may > >need changing some constants)? > > > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/C701D76E-A116-4D83-B427-24C305F51201%40gmail.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAGUWgD_ObgEtxC3Ok7%2BtHE174HS8kiUzbTC0y8%3D5Wdp%2B1QjNQw%40mail.gmail.com.
Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
On 12 April 2024 12:42:39 CEST, Georgi Guninski wrote: >On Fri, Apr 12, 2024 at 11:35 AM Dima Pasechnik wrote: >> >> This should be fixed by https://github.com/sagemath/sage/pull/37792 >> please review >> > >I suspect reproducing is hard, since it depends on the time of pressing CTL-C. Well, in all my tries the crash happened in the same place, the place that now is no longer reachable. And the reason for the crash was, AFAIU, due to calling a plain Python code (where Ctrl-C was caught) from a "noexcept" Cython code. That is, it's a crash due to inability to properly process Ctrl-C. How many more similar places are left there in Cython code in Sage, I don't know. Dima >Also, lack a crash may be silent memory corruption. > >It is weird that the crash is not always. > >Do you fix the attached new testcase (no interaction required, may >need changing some constants)? > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/C701D76E-A116-4D83-B427-24C305F51201%40gmail.com.
Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
On Fri, Apr 12, 2024 at 11:35 AM Dima Pasechnik wrote:
>
> This should be fixed by https://github.com/sagemath/sage/pull/37792
> please review
>
I suspect reproducing is hard, since it depends on the time of pressing CTL-C.
Also, lack a crash may be silent memory corruption.
It is weird that the crash is not always.
Do you fix the attached new testcase (no interaction required, may
need changing some constants)?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAGUWgD_5i%2BebLNsdJ4ZbaCuh_qcdMXtN2tkAaiByztA1oSOqTA%40mail.gmail.com.
"""
sage SEGV in solve_mod() + alarm() possibly related to signal
Author: Georgi Guninski
Fri Apr 12 09:49:15 AM UTC 2024
"""
def modcrash1(lim=100,seed=0):
#Author: Georgi Guninski
if seed != 0: set_random_seed(seed)
U=2000
L=U//2
x,y=var('x,y')
n=10**6
for i in range(lim):
S=randint(L,U)
print(i,S)
alarm(1.0*S/U)
try:
while True:
so=solve_mod(x*y-1,n)
cancel_alarm()
break
except: pass
cancel_alarm()
modcrash1()
Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
This should be fixed by https://github.com/sagemath/sage/pull/37792 please review On Thursday, April 11, 2024 at 10:19:31 PM UTC+1 dim...@gmail.com wrote: > On Thu, Apr 11, 2024 at 03:30:34PM +0300, Georgi Guninski wrote: > > Are the non-crashing codepaths in consistent state? > > SEGV is in general sign of memory corruption and it may lead to wrong > > math results or possibly have security implications. > > Here is an attempt to fix it; it appears that the call to > characteristic() which causes a crash is a leftover which can simply be > removed. > https://github.com/dimpase/sage/pull/6 > (not yet a PR to the Sage repo, just want to see results of tests) > > Dima > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/8d176b7d-a826-4713-ac3a-2a19c1c75669n%40googlegroups.com.
Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
On Thu, Apr 11, 2024 at 03:30:34PM +0300, Georgi Guninski wrote: > Are the non-crashing codepaths in consistent state? > SEGV is in general sign of memory corruption and it may lead to wrong > math results or possibly have security implications. Here is an attempt to fix it; it appears that the call to characteristic() which causes a crash is a leftover which can simply be removed. https://github.com/dimpase/sage/pull/6 (not yet a PR to the Sage repo, just want to see results of tests) Dima -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ZhhTnNiy9fsLjcVJ%40hilbert.homenet.telecomitalia.it. signature.asc Description: PGP signature
Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
Are the non-crashing codepaths in consistent state? SEGV is in general sign of memory corruption and it may lead to wrong math results or possibly have security implications. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAGUWgD-WWBUq7dyA-SWYrm761fKcQBe%3DRNkR_GL%3DxqZF%2BNveLA%40mail.gmail.com.
Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
On Thu, Apr 11, 2024 at 09:27:15AM +0300, Georgi Guninski wrote:
> Giving short testcase, can someone else reproduce it?
> Also attaching backtrace.
yes, I can reproduce this on a recent 10.4.beta - the backtrace I get it
more or less the same as the one attached - and it's in an unexpected to
me place, in src/sage/rings/finite_rings/integer_mod_ring.py.
If I read the backtrace right,
sa2si_ZZmod() - in Cython interface to Singular -
is called from Python code, then sa2si_ZZmod() calls characteristic() in the
line
nr2mModul = d.parent().characteristic()
As sa2si_ZZmod() is declared noexcept(), we see
Exception ignored in: 'sage.libs.singular.singular.sa2si_ZZmod'
But then in characteristic() an attempt to handle the exception is made,
and it leads to a crash. Should
nr2mModul = d.parent().characteristic()
be wrapped in some cysignals functions, or we currently just have to
means to deal with it?
KeyboardInterrupt:
sage: x,y=var('x,y');n=10**6
: while True: so=solve_mod(x*y-1,n)
^C---
KeyboardInterrupt Traceback (most recent call last)
File
/mnt/opt/Sage/sage-dev/src/sage/rings/finite_rings/integer_mod_ring.py:1029, in
IntegerModRing_generic.characteristic(self)
1025 ans.append(Factorization([(p, e - 1)]) *
1026factor(p - 1, int_=(self.__order < 2**31)))
1027 return ans
-> 1029 def characteristic(self):
1030 """
1031 EXAMPLES::
1032
(...)
1038 18
1039 """
1040 return self.__order
File src/cysignals/signals.pyx:341, in
cysignals.signals.python_check_interrupt()
KeyboardInterrupt:
Exception ignored in: 'sage.libs.singular.singular.sa2si_ZZmod'
Traceback (most recent call last):
File
"/mnt/opt/Sage/sage-dev/src/sage/rings/finite_rings/integer_mod_ring.py", line
1029, in characteristic
def characteristic(self):
File "src/cysignals/signals.pyx", line 341, in
cysignals.signals.python_check_interrupt
KeyboardInterrupt:
/usr/lib/python3.11/site-packages/cysignals/signals.cpython-311-x86_64-linux-gnu.so(+0x9beb)[0x7f0fea9a6beb]
/usr/lib/python3.11/site-packages/cysignals/signals.cpython-311-x86_64-linux-gnu.so(+0x9caf)[0x7f0fea9a6caf]
/usr/lib/python3.11/site-packages/cysignals/signals.cpython-311-x86_64-linux-gnu.so(+0xb7d0)[0x7f0fea9a87d0]
/lib64/libc.so.6(+0x39660)[0x7f0ff85a0660]
/usr/lib64/libgmp.so.10(__gmpz_cmp_ui+0x0)[0x7f0fe9b96a20]
/usr/lib64/libpolys-4.3.2.so(+0xf9dce)[0x7f0e9ceb1dce]
/mnt/opt/Sage/sage-dev/src/sage/libs/singular/polynomial.cpython-311-x86_64-linux-gnu.so(+0x7427)[0x7f0e9d22d427]
/mnt/opt/Sage/sage-dev/src/sage/rings/polynomial/multi_polynomial_libsingular.cpython-311-x86_64-linux-gnu.so(+0x4c072)[0x7f0e9d284072]
/mnt/opt/Sage/sage-dev/src/sage/rings/polynomial/multi_polynomial_libsingular.cpython-311-x86_64-linux-gnu.so(+0x4c908)[0x7f0e9d284908]
/usr/lib64/libpython3.11.so.1.0(+0x1acf22)[0x7f0ff88d1f22]
/mnt/opt/Sage/sage-dev/src/sage/rings/polynomial/polynomial_element.cpython-311-x86_64-linux-gnu.so(+0x2d6ea)[0x7f0fa1bb16ea]
/mnt/opt/Sage/sage-dev/src/sage/rings/polynomial/polynomial_element.cpython-311-x86_64-linux-gnu.so(+0x2dc8d)[0x7f0fa1bb1c8d]
/usr/lib64/libpython3.11.so.1.0(+0x1acf22)[0x7f0ff88d1f22]
/mnt/opt/Sage/sage-dev/src/sage/categories/map.cpython-311-x86_64-linux-gnu.so(+0x13db0)[0x7f0fe93e8db0]
/mnt/opt/Sage/sage-dev/src/sage/structure/parent.cpython-311-x86_64-linux-gnu.so(+0x2dbb9)[0x7f0fe9445bb9]
/mnt/opt/Sage/sage-dev/src/sage/rings/polynomial/multi_polynomial_libsingular.cpython-311-x86_64-linux-gnu.so(+0x6fe67)[0x7f0e9d2a7e67]
/usr/lib64/libpython3.11.so.1.0(_PyObject_Call+0x68)[0x7f0ff887fa28]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x57e3)[0x7f0ff8825613]
/usr/lib64/libpython3.11.so.1.0(+0x1741f5)[0x7f0ff88991f5]
/usr/lib64/libpython3.11.so.1.0(+0x252600)[0x7f0ff8977600]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x6daf)[0x7f0ff8826bdf]
/usr/lib64/libpython3.11.so.1.0(+0x1741f5)[0x7f0ff88991f5]
/usr/lib64/libpython3.11.so.1.0(+0x186381)[0x7f0ff88ab381]
/usr/lib64/libpython3.11.so.1.0(+0x1867cc)[0x7f0ff88ab7cc]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x7034)[0x7f0ff8826e64]
/usr/lib64/libpython3.11.so.1.0(PyEval_EvalCode+0x22c)[0x7f0ff897fecc]
/usr/lib64/libpython3.11.so.1.0(+0x255b50)[0x7f0ff897ab50]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x699d)[0x7f0ff88267cd]
/usr/lib64/libpython3.11.so.1.0(+0x1738dd)[0x7f0ff88988dd]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0xa61d)[0x7f0ff882a44d]
/usr/lib64/libpython3.11.so.1.0(+0x1738dd)[0x7f0ff88988dd]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0xa61d)[0x7f0ff882a44d]
/usr/lib64/libpython3.11.so.1.0(+0x174a95)[0x7f0ff8899a95]
/usr
Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
Giving short testcase, can someone else reproduce it?
Also attaching backtrace.
On second thought, if I don't crash, there could be some memory
corruption and sage runs with screwed memory.
```
x,y=var('x,y');n=10**6
while True: so=solve_mod(x*y-1,n)
#press CTL-C, crashes with probability about 1/3
```
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAGUWgD-B1von8U5avHrchNONmQ1Qzr9TtiwpF6OCzhNdW05D%3Dg%40mail.gmail.com.
1056 return self.__order
KeyboardInterrupt:
Exception ignored in: 'sage.libs.singular.singular.sa2si_ZZmod'
Traceback (most recent call last):
File
"/usr/lib64/python3.11/site-packages/sage/rings/finite_rings/integer_mod_ring.py",
line 1045, in characteristic
def characteristic(self):
KeyboardInterrupt:
/usr/lib64/python3.11/site-packages/cysignals/signals.cpython-311-x86_64-linux-gnu.so(+0x8329)[0x7f7109fa1329]
/usr/lib64/python3.11/site-packages/cysignals/signals.cpython-311-x86_64-linux-gnu.so(+0x85f9)[0x7f7109fa15f9]
/usr/lib64/python3.11/site-packages/cysignals/signals.cpython-311-x86_64-linux-gnu.so(+0xae3e)[0x7f7109fa3e3e]
/lib64/libc.so.6(+0x3dbb0)[0x7f7117c5fbb0]
/lib64/libgmp.so.10(__gmpz_cmp_ui+0x4)[0x7f7109572f74]
/usr/lib64/sagemath/local/lib/libpolys-4.3.1.so(+0xdb672)[0x7f70b2f9c672]
/usr/lib64/python3.11/site-packages/sage/libs/singular/polynomial.cpython-311-x86_64-linux-gnu.so(+0x791f)[0x7f70b299191f]
/usr/lib64/python3.11/site-packages/sage/rings/polynomial/multi_polynomial_libsingular.cpython-311-x86_64-linux-gnu.so(+0x35103)[0x7f70b341e103]
/usr/lib64/python3.11/site-packages/sage/rings/polynomial/multi_polynomial_libsingular.cpython-311-x86_64-linux-gnu.so(+0x356fa)[0x7f70b341e6fa]
/lib64/libpython3.11.so.1.0(+0x1cf151)[0x7f7117fcf151]
/usr/lib64/python3.11/site-packages/sage/rings/polynomial/polynomial_element.cpython-311-x86_64-linux-gnu.so(+0x14dfeb)[0x7f70c1488feb]
/usr/lib64/python3.11/site-packages/sage/rings/polynomial/polynomial_element.cpython-311-x86_64-linux-gnu.so(+0x14e566)[0x7f70c1489566]
/usr/lib64/python3.11/site-packages/sage/categories/map.cpython-311-x86_64-linux-gnu.so(+0x1cb1e)[0x7f7108fc5b1e]
/usr/lib64/python3.11/site-packages/sage/structure/parent.cpython-311-x86_64-linux-gnu.so(+0x19108)[0x7f7109002108]
/usr/lib64/python3.11/site-packages/sage/rings/polynomial/multi_polynomial_libsingular.cpython-311-x86_64-linux-gnu.so(+0x376d8)[0x7f70b34206d8]
/lib64/libpython3.11.so.1.0(_PyObject_Call+0x79)[0x7f7117fe06b9]
/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x4c1a)[0x7f7117fbf7ba]
/lib64/libpython3.11.so.1.0(+0x1eed6a)[0x7f7117feed6a]
/lib64/libpython3.11.so.1.0(+0x1fb026)[0x7f7117ffb026]
/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0xbc5)[0x7f7117fbb765]
/lib64/libpython3.11.so.1.0(+0x1eed6a)[0x7f7117feed6a]
/lib64/libpython3.11.so.1.0(+0x1eebf8)[0x7f7117feebf8]
/lib64/libpython3.11.so.1.0(+0x1ed8d5)[0x7f7117fed8d5]
/lib64/libpython3.11.so.1.0(+0x20bcb1)[0x7f711800bcb1]
/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x2cce)[0x7f7117fbd86e]
/lib64/libpython3.11.so.1.0(+0x1b753a)[0x7f7117fb753a]
/lib64/libpython3.11.so.1.0(PyEval_EvalCode+0xac)[0x7f711803d99c]
/lib64/libpython3.11.so.1.0(+0x253cc2)[0x7f7118053cc2]
/lib64/libpython3.11.so.1.0(+0x1c875a)[0x7f7117fc875a]
/lib64/libpython3.11.so.1.0(PyObject_Vectorcall+0x37)[0x7f7117fc86c7]
/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x72d)[0x7f7117fbb2cd]
/lib64/libpython3.11.so.1.0(+0x1eed6a)[0x7f7117feed6a]
/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x358a)[0x7f7117fbe12a]
/lib64/libpython3.11.so.1.0(+0x1eed6a)[0x7f7117feed6a]
/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x358a)[0x7f7117fbe12a]
/lib64/libpython3.11.so.1.0(+0x1eed6a)[0x7f7117feed6a]
/lib64/libpython3.11.so.1.0(+0x251c57)[0x7f7118051c57]
/lib64/libpython3.11.so.1.0(+0x1df934)[0x7f7117fdf934]
/lib64/libpython3.11.so.1.0(PyObject_Vectorcall+0x37)[0x7f7117fc86c7]
/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x72d)[0x7f7117fbb2cd]
/lib64/libpython3.11.so.1.0(+0x1b753a)[0x7f7117fb753a]
/lib64/libpython3.11.so.1.0(PyEval_EvalCode+0xac)[0x7f711803d99c]
/lib64/libpython3.11.so.1.0(+0x25aa63)[0x7f711805aa63]
/lib64/libpython3.11.so.1.0(+0x256efa)[0x7f7118056efa]
/lib64/libpython3.11.so.1.0(+0x26c342)[0x7f711806c342]
/lib64/libpython3.11.so.1.0(_PyRun_SimpleFileObject+0x1b8)[0x7f711806bb28]
/lib64/libpython3.11.so.1.0(_PyRun_AnyFileObject+0x48)[0x7f711806b7e8]
/lib64/libpython3.11.so.1.0(Py_RunMain+0x358)[0x7f71180660a8]
/lib64/libpython3.11.so.1.0(Py_BytesMain+0x3b)[0x7f711802dc0b]
/lib64/libc.so.6(+0x27b8a)[0x7f7117c49b8a]
/lib64/libc.so.6(__libc_start_main+0x8b)[0x7f7117c49c4b]
/usr/bin/python3(_start+0x25)[0x560df1abc095]
-
Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
Also not that there is plenty of code that, in the course of computation, writes into attributes of objects. If you're doing multiple of those it's very hard in python to make such a modification atomic. So if an interrupt ends up splitting an update, you may leave the system in an inconsistent state that could affect future computations. It's a nice aspirational goal to have Ctrl-C work decently, but if you want your results with a reasonably degree of confidence in correctness, you should probably avoid interruptions anyway. Most code is hopefully written defensively: work on a local copy and only in the last bit modify the attribute by a single assignment. That minimizes the chance for getting inconsistent states from interrupts, but I don't think you'll get it to zero, because of the non-atomicity of multiple attribute assignments. On Wednesday 10 April 2024 at 11:03:13 UTC-7 Vincent Delecroix wrote: > I do not remember anything specific about solve_mod. Though, there are > many places in Cython source code where sig_on/sig_off is not handled > carefully enough (and many that were fixed). > > The fact that it is not reproducible is not necessarily a huge problem. > However, > - Could you share the code (as minimal as possible) that provokes this > on your machine? > - Do you have the complete (C) trace of the crash? You might need to > install gdb depending on your setup. > > Vincent > > On Wed, 10 Apr 2024 at 16:18, Georgi Guninski wrote: > > > > I don't have reproducible testcase, but my pain is that sometimes if I > > press CTL-C e.g. when solve_mod() is called in a loop, I get SEGV and > > abort. > > I suspect besides signals, it is hitting race condition. > > Is this a known issue? > > > > Very long ago there was vulnerability in sendmail, where it did > > printf() or similar in signal handler and this was documented in the > > literature. > > > > -- > > You received this message because you are subscribed to the Google > Groups "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to sage-devel+...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/CAGUWgD_7t9OTNdo6Ovrt%3DJdNqmGJLPGsZHVoJK0mNPQhuz1CKQ%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b7d35f4e-7301-4ac4-8cf1-561ba86493e0n%40googlegroups.com.
Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
I do not remember anything specific about solve_mod. Though, there are many places in Cython source code where sig_on/sig_off is not handled carefully enough (and many that were fixed). The fact that it is not reproducible is not necessarily a huge problem. However, - Could you share the code (as minimal as possible) that provokes this on your machine? - Do you have the complete (C) trace of the crash? You might need to install gdb depending on your setup. Vincent On Wed, 10 Apr 2024 at 16:18, Georgi Guninski wrote: > > I don't have reproducible testcase, but my pain is that sometimes if I > press CTL-C e.g. when solve_mod() is called in a loop, I get SEGV and > abort. > I suspect besides signals, it is hitting race condition. > Is this a known issue? > > Very long ago there was vulnerability in sendmail, where it did > printf() or similar in signal handler and this was documented in the > literature. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/CAGUWgD_7t9OTNdo6Ovrt%3DJdNqmGJLPGsZHVoJK0mNPQhuz1CKQ%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAGEwAAkUS4secJzvZJfSVivuqoKwnUUGSjPxi2aUAuTY2MinBw%40mail.gmail.com.
[sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals
I don't have reproducible testcase, but my pain is that sometimes if I press CTL-C e.g. when solve_mod() is called in a loop, I get SEGV and abort. I suspect besides signals, it is hitting race condition. Is this a known issue? Very long ago there was vulnerability in sendmail, where it did printf() or similar in signal handler and this was documented in the literature. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAGUWgD_7t9OTNdo6Ovrt%3DJdNqmGJLPGsZHVoJK0mNPQhuz1CKQ%40mail.gmail.com.
