sbcl on msys2 on windows Re: [fricas-devel] [windows] no sman on msys2/mingw64

[Qian Yun]

On 3/5/21 12:27, oldk1331 wrote:

THANK YOU both, Dima and Waldek.

Now I understand the difference between "msys2 shell" and
"mingw 64bit shell".

Indeed, in "msys2 shell", there are "fork".  (They partly
re-implement cygwin?).

So, in "msys2 shell", we can build sman successfully.
But when building algebra, SBCL encounters strange memory
fault, which I'll look into later.  And right now, sman
from msys2 shell does not mix well with FriCASsys from
mingw64 shell.


The memory fault happens if FriCASsys loads "libspad.so".
Probably the same thing for cygwin.

Obviously FFI works for SBCL on Windows.  Now I need to
find out where went wrong in our build process.

- Qian


I'll continue explore the possibility from "msys2 shell".

On 3/5/21 12:31 AM, Dima Pasechnik wrote:
 > On Thu, Mar 4, 2021 at 4:26 PM Qian Yun > wrote:

 >>
 >> Wait a second, there are numerous packages on msys2/mingw64
 >> that uses fork and pty, how does that happen?
 > Could you point at any such package, with an URL?
 >
 > you probably mix it up with cygwin (which does support fork() etc)
 >


On 3/5/21 1:18 AM, Waldek Hebisch wrote:
  >
  > IIUC msys uses (or maybe re-implements) Cygwin emulation
  > of fork and pty.  Fork is emulated in rather crude way
  > and tends to fail from time to time.  I did not look
  > how pty emulation works.
  >
  > My point was that we can with moderate effort avoid
  > use of fork.  ATM avoidning pty would be much more tricky.
  >


--
You received this message because you are subscribed to the Google Groups "FriCAS - 
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/c7fe63bb-aa3b-b2f0-a685-c5274983289d%40gmail.com.

Re: [fricas-devel] Fixing latex generated so not to use \over. Causes latex to hang when using breqn package

[Waldek Hebisch]

On Thu, May 26, 2022 at 01:57:33AM +, I wrote:
> On Wed, May 25, 2022 at 12:47:47PM -0700, 'Nasser M. Abbasi' via FriCAS - 
> computer algebra system wrote:
> > 
> > Fricas uses very old and not recommended \over when it generates latex.
> > This causes modern compilers such as lualatex to hang when using dmath 
> > environment.
> > 
> > Could the latex be corrected to use \frac{} instead?
> 
> As Ralf wrote FormatLaTeX is LaTeX only and generates '\frac'.
> 
> Since LaTeX packages you mention have trouble with '\over' it make sense
> to make choice in TexFormat between '\frac' and '\over' configurable.
> It even makes sense to make '\frac' a default (because plain TeX
> gets much less use than in the past).

I have now commited such change: TexFormat generates '\frac' by
default and when you do setDialect('plain) it generates '\over'.

-- 
  Waldek Hebisch

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20220618020943.GA11982%40fricas.math.uni.wroc.pl.

Re: [fricas-devel] "allocate-vector" not defined since sbcl-2.1.5

[Waldek Hebisch]

On Fri, Jun 17, 2022 at 09:12:42PM +0800, Qian Yun wrote:
> "SB-KERNEL:ALLOCATE-VECTOR" is not defined since sbcl-2.1.5,
> to be precise, it is this commit:
> https://github.com/sbcl/sbcl/commit/3203ba3ac5f2c3d59c25825c90fb6e8d637e8af8
> 
> Clearly this would affect FriCAS's performance.

This is handled by our code: in relevant case also other functions
are missing, we detect this and revert to generic method.

Concerning performance: in older sbcl 'make-array' for specialized
arrays had really bad performance, so our code was really important.
In newer sbcl 'make-array' is faster, so using it is no so bad...

-- 
  Waldek Hebisch

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20220618020500.GB10710%40fricas.math.uni.wroc.pl.

[fricas-devel] Re: "allocate-vector" not defined since sbcl-2.1.5

[Qian Yun]

So the sbcl maintainers say why not use "make-array" directly.

So the usage of sbcl internals was to speed up "make-array".
They were added in the past to speed up old version of sbcl
Now I wonder if our current pile of code still matters.

- Qian

On 6/17/22 21:12, Qian Yun wrote:

"SB-KERNEL:ALLOCATE-VECTOR" is not defined since sbcl-2.1.5,
to be precise, it is this commit:
https://github.com/sbcl/sbcl/commit/3203ba3ac5f2c3d59c25825c90fb6e8d637e8af8 



Clearly this would affect FriCAS's performance.

Not sure if this is a sbcl bug, I'll report on their mail list.

- Qian


--
You received this message because you are subscribed to the Google Groups "FriCAS - 
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/8016c1c7-c8b1-216c-1521-f3b846b47b8e%40gmail.com.

Re: [fricas-devel] [BUG] sman causes endless loop if libraries required by viewman does not exist

[Qian Yun]

On 6/18/22 09:23, Waldek Hebisch wrote:


_Assuming_ our programs are correct reasonable reason for dying
is some _intermittent_ system problem.  Like getting wrong bits
from RAM/HDD or OOM killer making wrong choice.  Even in case
of bugs intermittent bugs are quite likely, viewman deals
with sockects and related timing issues so lot of things
are nondeterministic.  Deterministic bugs can be found and fixed
much easier than intermittent ones, so after some time spent on
debugging remaining bugs are likely to be intermittent...


That is from programmer's side of view.

My point of view is from user's side, about user friendly:

1. A user downloaded fricas binary to a home linux server,
or a cloud linux server, or a linux super computer to try
it out.  Run "fricas" and get into endless error message.

2. A user downloaded fricas binary to macOS computer.
Double click the icon and get into endless error message.

3. A user downloaded fricas binary to Windows.
(I'm close to have sbcl with sman/hyperdoc work on windows.)
Double click the icon and get into endless error message.



More to the point: you looked at respawning issue because
there were missing library.  Missing library means broken
installation.  So real fix is to make sure that library is
present.  IIUC when building from source link stage will
fail in case of missing libraries.  So only binary install
should matter.  If install is done by some tool (script) the
tool is supposed to ensure that libraries are present.
If user is using simple binary tarball like I provide,
this tarball have stated dependencies and user is supposed
to install them.  Failing to install them may lead to
non-working FriCAS.  Since user will get error message
I do not see this as significant issue: user made mistake,
user got error message, user will correct the problem.


Again, user friendly issue.  Windows and macOS users can
not install dependencies as easy as Linux users.

I just want these users can use command line interface
of fricas when X11 libs not present. Fallback gracefully,
If they go extra mile and install X11 libs, then they get
hyerDoc and drawing ability.


I did eliminate some things of similar spirit, but my
procedure was to make modification in my local copy of
FriCAS, use it for some time (say a year), and commit
only if I so no bad effects of the change.  And in
few cases I had noticed that seemingly useless code
in fact was doing useful thing, to I reverted the change.



I will apply it locally and submit it again next year then.

- Qian

--
You received this message because you are subscribed to the Google Groups "FriCAS - 
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/b0992615-e557-ccc4-8a34-9d4c9049e30f%40gmail.com.

Re: [fricas-devel] [BUG] sman causes endless loop if libraries required by viewman does not exist

[Waldek Hebisch]

On Wed, Jun 15, 2022 at 09:05:48AM +0800, Qian Yun wrote:
> 
> On 6/15/22 00:28, Waldek Hebisch wrote:
> >
> >If you take seriously possibility that viewman may die, then
> >natural thing is to automatically restart it.  And this is
> >what 'sman' is doing now.
> >
> 
> First, the source code of viewman is pretty short and simple,
> so it is unlikely to die.
> 
> Second, if in the unlikely cases that viewman dies for some
> reason, and sman restarts it, it is very likely that
> viewman will die again for the same reason.  And now it is
> in infinite loop.  Which is the problem I encountered in the
> first place.

_Assuming_ our programs are correct reasonable reason for dying
is some _intermittent_ system problem.  Like getting wrong bits
from RAM/HDD or OOM killer making wrong choice.  Even in case
of bugs intermittent bugs are quite likely, viewman deals
with sockects and related timing issues so lot of things
are nondeterministic.  Deterministic bugs can be found and fixed
much easier than intermittent ones, so after some time spent on
debugging remaining bugs are likely to be intermittent...

More to the point: you looked at respawning issue because
there were missing library.  Missing library means broken
installation.  So real fix is to make sure that library is
present.  IIUC when building from source link stage will
fail in case of missing libraries.  So only binary install
should matter.  If install is done by some tool (script) the
tool is supposed to ensure that libraries are present.
If user is using simple binary tarball like I provide,
this tarball have stated dependencies and user is supposed
to install them.  Failing to install them may lead to
non-working FriCAS.  Since user will get error message
I do not see this as significant issue: user made mistake,
user got error message, user will correct the problem.

Coming back to respawning: I do not know if it is really
necessary.  It may be just defensive programming
(sensible because modern OS-es work essentialy in
probablistic way, with small but nonzero probablity
you may get essentially random failures).  It may be
attempt at masking errors: incorrect programming may
increase chance of error enough to be a trouble,
respawning may mask it.

I did eliminate some things of similar spirit, but my
procedure was to make modification in my local copy of
FriCAS, use it for some time (say a year), and commit
only if I so no bad effects of the change.  And in
few cases I had noticed that seemingly useless code
in fact was doing useful thing, to I reverted the change.

-- 
  Waldek Hebisch

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20220618012359.GA10710%40fricas.math.uni.wroc.pl.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[Kurt Pagani]

On 17.06.2022 14:58, Qian Yun wrote:
> echo 100 | sudo tee /proc/sys/kernel/ns_last_pid
Hi Qian
Indeed!

---
fp@sirius:~$ echo 100 | sudo tee /proc/sys/kernel/ns_last_pid

100

kfp@sirius:~$ fricas

viewman not present, disabling graphics
hypertex  not present, disabling
*** buffer overflow detected ***: terminated
Aborted (core dumped)

kfp@sirius:~$ uname -a
Linux sirius 5.13.0-48-generic #54-Ubuntu SMP Wed Jun 1 20:38:48 UTC 2022 x86_64
x86_64 x86_64 GNU/Linux

kfp@sirius:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 21.10"
NAME="Ubuntu"
VERSION_ID="21.10"
VERSION="21.10 (Impish Indri)"
VERSION_CODENAME=impish
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/;
SUPPORT_URL="https://help.ubuntu.com/;
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
UBUNTU_CODENAME=impish

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/b20afdd8-7a57-b9f1-dfaa-b84eb2e1cfe2%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[Bill Page]

Sorry, I forgot you also wanted to know which Linux.

wspage@ASUS:~/Desktop$ uname -r
5.4.0-120-generic
wspage@ASUS:~/Desktop$ cat /etc/os-release
NAME="Linux Mint"
VERSION="20.3 (Una)"
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME="Linux Mint 20.3"
VERSION_ID="20.3"
HOME_URL="https://www.linuxmint.com/;
SUPPORT_URL="https://forums.linuxmint.com/;
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/;
PRIVACY_POLICY_URL="https://www.linuxmint.com/;
VERSION_CODENAME=una
UBUNTU_CODENAME=focal

On Fri, 17 Jun 2022 at 12:19, Bill Page  wrote:
>
> When I do this
>
> wspage@ASUS:~/Desktop$ echo 100 | sudo tee /proc/sys/kernel/ns_last_pid
>
> and then run fricas I get
>
> wspage@ASUS:~/Desktop$ fricas
>
> debugger invoked on a SIMPLE-ERROR in thread
> #:
>   Error opening shared object "libssl.so.1.0.0":
>   libssl.so.1.0.0: cannot open shared object file: No such file or directory.
>
> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
>   0: [CONTINUE   ] Skip this shared object and continue.
>   1: [RETRY  ] Retry loading this shared object.
>   2: [CHANGE-PATHNAME] Specify a different pathname to load the shared
> object from.
>   3: [ABORT  ] Exit from the current thread.
>
> (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME
> #P"libssl.so.1.0.0" :NAMESTRING "libssl.so.1.0.0" :HANDLE NIL
> :DONT-SAVE NIL))
> 0] (HyperDoc) Error opening FriCAS server. Retrying ...
> (HyperDoc) Couldn't connect to FriCAS server!
> (HyperDoc) Couldn't connect to FriCAS server!
> ^C
> ^C does not break out of the loop and the session appears hung. So ...
> ^Z
> [1]+  Stopped fricas
> wspage@ASUS:~/Desktop$ kill %1
>
> On Fri, 17 Jun 2022 at 08:59, Qian Yun  wrote:
> >
> > Hello everyone,
> >
> > I would like to know if your system is affected as well.
> > You can simply bump your system's next PID by:
> >
> >  echo 100 | sudo tee /proc/sys/kernel/ns_last_pid
> >
> > Run "fricas" and see if it has buffer overflow error message.
> >
> > If you do have such error message, please reply this email
> > with your Linux distro's version.
> >
> > If you do not have problem, you can reply if you like.
> >
> > - Thanks,
> > - Qian
> >
> > On 6/17/22 20:46, Qian Yun wrote:
> > > And we do not propagate CFLAGS properly, so we can not
> > > use "make CFLAGS=-D_FORTIFY_SOURCE=1" to slip in this
> > > workaround.
> > >
> > > - Qian
> > >
> > > On 6/13/22 23:03, Qian Yun wrote:
> > >> Hi Waldek,
> > >>
> > >> The original problem still exists:
> > >>
> > >> I can still get
> > >>  "*** buffer overflow detected ***: terminated"
> > >> when PID goes over 1 million.
> > >>
> > >> That's because on my system GCC has auto hardening feature.
> > >> (This feature should be popular on other distros as well.)
> > >> To be precise, GCC automatically compiles with
> > >> "-D_FORTIFY_SOURCE=2".  This is adding runtime checks
> > >> that gives this particular error.
> > >>
> > >> Turning it down to "-D_FORTIFY_SOURCE=1" can prevent
> > >> this problem.
> > >>
> > >> However, I still think using "0-9a-z" to encode socket
> > >> address is a better solution.
> > >>
> > >> - Qian
> > >>
> > >> On 9/9/20 18:30, Waldek Hebisch wrote:
> > >>> On Wed, Sep 09, 2020 at 06:08:32PM +0800, oldk1331 wrote:
> > 
> > > What about the attached patch.  It skips 'memset' which seem
> > > to be not needed at all and cleans up relevant parts.
> > 
> >  Hi Waldek, I'm afraid you forget to include the attachment.
> > 
> > >>> Oops, second time.
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "FriCAS - computer algebra system" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to fricas-devel+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/fricas-devel/c7fcd63a-e746-bbf0-3a4a-160efe4dc485%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAC6x94T4w-SzMmNsaR3CgMo%3DA8kxLY8S1REF41oz27tJ2VMz%3Dg%40mail.gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[Bill Page]

When I do this

wspage@ASUS:~/Desktop$ echo 100 | sudo tee /proc/sys/kernel/ns_last_pid

and then run fricas I get

wspage@ASUS:~/Desktop$ fricas

debugger invoked on a SIMPLE-ERROR in thread
#:
  Error opening shared object "libssl.so.1.0.0":
  libssl.so.1.0.0: cannot open shared object file: No such file or directory.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE   ] Skip this shared object and continue.
  1: [RETRY  ] Retry loading this shared object.
  2: [CHANGE-PATHNAME] Specify a different pathname to load the shared
object from.
  3: [ABORT  ] Exit from the current thread.

(SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME
#P"libssl.so.1.0.0" :NAMESTRING "libssl.so.1.0.0" :HANDLE NIL
:DONT-SAVE NIL))
0] (HyperDoc) Error opening FriCAS server. Retrying ...
(HyperDoc) Couldn't connect to FriCAS server!
(HyperDoc) Couldn't connect to FriCAS server!
^C
^C does not break out of the loop and the session appears hung. So ...
^Z
[1]+  Stopped fricas
wspage@ASUS:~/Desktop$ kill %1

On Fri, 17 Jun 2022 at 08:59, Qian Yun  wrote:
>
> Hello everyone,
>
> I would like to know if your system is affected as well.
> You can simply bump your system's next PID by:
>
>  echo 100 | sudo tee /proc/sys/kernel/ns_last_pid
>
> Run "fricas" and see if it has buffer overflow error message.
>
> If you do have such error message, please reply this email
> with your Linux distro's version.
>
> If you do not have problem, you can reply if you like.
>
> - Thanks,
> - Qian
>
> On 6/17/22 20:46, Qian Yun wrote:
> > And we do not propagate CFLAGS properly, so we can not
> > use "make CFLAGS=-D_FORTIFY_SOURCE=1" to slip in this
> > workaround.
> >
> > - Qian
> >
> > On 6/13/22 23:03, Qian Yun wrote:
> >> Hi Waldek,
> >>
> >> The original problem still exists:
> >>
> >> I can still get
> >>  "*** buffer overflow detected ***: terminated"
> >> when PID goes over 1 million.
> >>
> >> That's because on my system GCC has auto hardening feature.
> >> (This feature should be popular on other distros as well.)
> >> To be precise, GCC automatically compiles with
> >> "-D_FORTIFY_SOURCE=2".  This is adding runtime checks
> >> that gives this particular error.
> >>
> >> Turning it down to "-D_FORTIFY_SOURCE=1" can prevent
> >> this problem.
> >>
> >> However, I still think using "0-9a-z" to encode socket
> >> address is a better solution.
> >>
> >> - Qian
> >>
> >> On 9/9/20 18:30, Waldek Hebisch wrote:
> >>> On Wed, Sep 09, 2020 at 06:08:32PM +0800, oldk1331 wrote:
> 
> > What about the attached patch.  It skips 'memset' which seem
> > to be not needed at all and cleans up relevant parts.
> 
>  Hi Waldek, I'm afraid you forget to include the attachment.
> 
> >>> Oops, second time.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to fricas-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/c7fcd63a-e746-bbf0-3a4a-160efe4dc485%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAC6x94QGqVdu4H%2BTMexbHUGZ9eGspx-mkU831O8x4HB1CyTRyQ%40mail.gmail.com.

[fricas-devel] Re: "SB-KERNEL:ALLOCATE-VECTOR" is not defined after sbcl-2.1.5

[Qian Yun]

Oops, this was meant for sbcl-bugs list.  Please ignore.

On 6/17/22 21:44, Qian Yun wrote:

"SB-KERNEL:ALLOCATE-VECTOR" is not defined after sbcl-2.1.5,
to be precise, this happens in
3203ba3ac5f2c3d59c25825c90fb6e8d637e8af8.

We were using it for optimization (create vector with elements of
8 bit integer, for example).

So I'm not sure if this removal is intentional.  After all,
ALLOCATE-VECTOR is still exported by package SB-KERNEL.

If the removal is intentional, can you tell me what the
proper replacement is?

- Qian


--
You received this message because you are subscribed to the Google Groups "FriCAS - 
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/281c4653-fd05-ae2b-eca8-0ad36f979b1f%40gmail.com.

[fricas-devel] "SB-KERNEL:ALLOCATE-VECTOR" is not defined after sbcl-2.1.5

[Qian Yun]

"SB-KERNEL:ALLOCATE-VECTOR" is not defined after sbcl-2.1.5,
to be precise, this happens in
3203ba3ac5f2c3d59c25825c90fb6e8d637e8af8.

We were using it for optimization (create vector with elements of
8 bit integer, for example).

So I'm not sure if this removal is intentional.  After all,
ALLOCATE-VECTOR is still exported by package SB-KERNEL.

If the removal is intentional, can you tell me what the
proper replacement is?

- Qian

--
You received this message because you are subscribed to the Google Groups "FriCAS - 
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/cbd75cd5-c42c-31a1-f701-004d6cbe3024%40gmail.com.

[fricas-devel] "allocate-vector" not defined since sbcl-2.1.5

[Qian Yun]

"SB-KERNEL:ALLOCATE-VECTOR" is not defined since sbcl-2.1.5,
to be precise, it is this commit:
https://github.com/sbcl/sbcl/commit/3203ba3ac5f2c3d59c25825c90fb6e8d637e8af8

Clearly this would affect FriCAS's performance.

Not sure if this is a sbcl bug, I'll report on their mail list.

- Qian

--
You received this message because you are subscribed to the Google Groups "FriCAS - 
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/9818f5f7-6ba6-d03d-5fe5-62738997e0f8%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[Qian Yun]

Hello everyone,

I would like to know if your system is affected as well.
You can simply bump your system's next PID by:

echo 100 | sudo tee /proc/sys/kernel/ns_last_pid

Run "fricas" and see if it has buffer overflow error message.

If you do have such error message, please reply this email
with your Linux distro's version.

If you do not have problem, you can reply if you like.

- Thanks,
- Qian

On 6/17/22 20:46, Qian Yun wrote:

And we do not propagate CFLAGS properly, so we can not
use "make CFLAGS=-D_FORTIFY_SOURCE=1" to slip in this
workaround.

- Qian

On 6/13/22 23:03, Qian Yun wrote:

Hi Waldek,

The original problem still exists:

I can still get
 "*** buffer overflow detected ***: terminated"
when PID goes over 1 million.

That's because on my system GCC has auto hardening feature.
(This feature should be popular on other distros as well.)
To be precise, GCC automatically compiles with
"-D_FORTIFY_SOURCE=2".  This is adding runtime checks
that gives this particular error.

Turning it down to "-D_FORTIFY_SOURCE=1" can prevent
this problem.

However, I still think using "0-9a-z" to encode socket
address is a better solution.

- Qian

On 9/9/20 18:30, Waldek Hebisch wrote:

On Wed, Sep 09, 2020 at 06:08:32PM +0800, oldk1331 wrote:



What about the attached patch.  It skips 'memset' which seem
to be not needed at all and cleans up relevant parts.


Hi Waldek, I'm afraid you forget to include the attachment.


Oops, second time.


--
You received this message because you are subscribed to the Google Groups "FriCAS - 
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/c7fcd63a-e746-bbf0-3a4a-160efe4dc485%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[Qian Yun]

And we do not propagate CFLAGS properly, so we can not
use "make CFLAGS=-D_FORTIFY_SOURCE=1" to slip in this
workaround.

- Qian

On 6/13/22 23:03, Qian Yun wrote:

Hi Waldek,

The original problem still exists:

I can still get
     "*** buffer overflow detected ***: terminated"
when PID goes over 1 million.

That's because on my system GCC has auto hardening feature.
(This feature should be popular on other distros as well.)
To be precise, GCC automatically compiles with
"-D_FORTIFY_SOURCE=2".  This is adding runtime checks
that gives this particular error.

Turning it down to "-D_FORTIFY_SOURCE=1" can prevent
this problem.

However, I still think using "0-9a-z" to encode socket
address is a better solution.

- Qian

On 9/9/20 18:30, Waldek Hebisch wrote:

On Wed, Sep 09, 2020 at 06:08:32PM +0800, oldk1331 wrote:



What about the attached patch.  It skips 'memset' which seem
to be not needed at all and cleans up relevant parts.


Hi Waldek, I'm afraid you forget to include the attachment.


Oops, second time.


--
You received this message because you are subscribed to the Google Groups "FriCAS - 
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/8a635bab-2c80-4c91-1efc-308950f6e334%40gmail.com.