Updated, see:
https://github.com/oldk1331/fricas/commit/6af9de34eaab919ebb650e2bf00ac012f61a4aeb.patch
Or see at the end of this mail.
- Qian
On 6/28/22 07:14, Waldek Hebisch wrote:
On Mon, Jun 27, 2022 at 06:09:28PM +0800, Qian Yun wrote:
See branch at https://github.com/oldk1331/fricas/com
On Mon, Jun 27, 2022 at 06:09:28PM +0800, Qian Yun wrote:
>
> See branch at https://github.com/oldk1331/fricas/commits/fix-socket-unix
> Or the following diff.
>
> There can be further refinement, such as adjust "fricas_host_has_socket"
> in configure.ac.
That looks mostly OK. The little possib
On 6/27/22 01:28, Waldek Hebisch wrote:
I was thinking more in direction of having something like:
union {
#if defined(HAVE_SOCK_UN)
struct sockaddr_un u_addr;
#endif
struct sockaddr_in i_addr;
and similar in other places using sockaddr_un. And of course
we w
On Mon, Jun 27, 2022 at 12:13:58AM +0800, Qian Yun wrote:
>
>
> On 6/26/22 22:00, Waldek Hebisch wrote:
> >On Tue, Jun 21, 2022 at 10:15:27PM +0800, Qian Yun wrote:
> >>Can we try to fix this bug with 'sockaddr_un'?
> >
> >I am not sure what you mean here. We want ability to
> >handle both Unix
On 6/26/22 22:00, Waldek Hebisch wrote:
On Tue, Jun 21, 2022 at 10:15:27PM +0800, Qian Yun wrote:
Can we try to fix this bug with 'sockaddr_un'?
I am not sure what you mean here. We want ability to
handle both Unix domain sockets and Internet sockets.
With proper conditiononals this should
On Tue, Jun 21, 2022 at 10:15:27PM +0800, Qian Yun wrote:
> Can we try to fix this bug with 'sockaddr_un'?
I am not sure what you mean here. We want ability to
handle both Unix domain sockets and Internet sockets.
With proper conditiononals this should be possible.
So we could use 'sockaddr_un',
Can we try to fix this bug with 'sockaddr_un'?
About windows:
Cygwin should work, because it is an POSIX emulation layer.
Mingw64 (aka native WIN32) never worked: sman was never built
as WIN32. So on (native WIN32) windows, the socket related code
is never used, right?
The WinSock code was th
> "WH" == Waldek Hebisch writes:
WH> cat /proc/sys/kernel/pid_max
WH> 32768
which, btw, is the default value.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
%>echo 100 | sudo tee /proc/sys/kernel/ns_last_pid
100
%>fricas
*** buffer overflow detected ***: terminated
Aborted
%>cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
OK, understood.
So does
sudo sysctl -w kernel.pid_max=200
work for you?
- Qian
On 6/19/22 23:11, Waldek Hebisch wrote:
On Sun, Jun 19, 2022 at 10:42:13PM +0800, Qian Yun wrote:
Still not clear whether your /proc/sys/kernel/pid_max
is less than 1 million,
cat /proc/sys/kernel/pid_max
On Sun, Jun 19, 2022 at 10:42:13PM +0800, Qian Yun wrote:
> Still not clear whether your /proc/sys/kernel/pid_max
> is less than 1 million,
cat /proc/sys/kernel/pid_max
32768
> or you couldn't write to
> /proc/sys/kernel/ns_last_pid.
I can, but write fails when value is larger than pid_max.
>
Still not clear whether your /proc/sys/kernel/pid_max
is less than 1 million, or you couldn't write to
/proc/sys/kernel/ns_last_pid.
I wonder if you'd like to share your distro's
information and kernel version.
- Qian
On 6/19/22 21:45, Waldek Hebisch wrote:
On Sun, Jun 19, 2022 at 01:25:24PM +
On Sun, Jun 19, 2022 at 01:25:24PM +0800, Qian Yun wrote:
>
>
> On 6/18/22 19:44, Waldek Hebisch wrote:
> >On Mon, Jun 13, 2022 at 11:03:29PM +0800, Qian Yun wrote:
> >
> >There should be way to write the code so that it works
> >with -D_FORTIFY_SOURCE=2 and large PID-s. Unfortunately
> >on syst
On 6/18/22 19:44, Waldek Hebisch wrote:
On Mon, Jun 13, 2022 at 11:03:29PM +0800, Qian Yun wrote:
There should be way to write the code so that it works
with -D_FORTIFY_SOURCE=2 and large PID-s. Unfortunately
on systems that I use I can not set large PID-s.
Why can't your system set large
On Mon, Jun 13, 2022 at 11:03:29PM +0800, 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 s
On Fri, Jun 17, 2022 at 08:46:23PM +0800, 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.
If you do
export CC="gcc -D_FORTIFY_SOURCE=1"
before configure and make, than all compilations will use
provide
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 over
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/"
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:
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 em
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 ove
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
I tested, it works fine, please commit.
On Wed, Sep 9, 2020, 6:30 PM 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 Wal
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.
--
> 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.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" gr
On Mon, Aug 31, 2020 at 11:58:55AM +0800, oldk1331 wrote:
> On 8/30/20 9:51 PM, Waldek Hebisch wrote:
> > On Sun, Aug 30, 2020 at 08:39:32PM +0800, oldk1331 wrote:
> >>
> >> Hi Waldek,
> >>
> >> Your commit e68c2a3e doesn't work out of box on my system:
> >>
> >> The gcc or glibc on my system is ha
On 8/30/20 9:51 PM, Waldek Hebisch wrote:
> On Sun, Aug 30, 2020 at 08:39:32PM +0800, oldk1331 wrote:
>>
>> Hi Waldek,
>>
>> Your commit e68c2a3e doesn't work out of box on my system:
>>
>> The gcc or glibc on my system is hardened (might be true
>> for newer gcc/glibc on other systems as well), so
On Sun, Aug 30, 2020 at 08:39:32PM +0800, oldk1331 wrote:
>
> Hi Waldek,
>
> Your commit e68c2a3e doesn't work out of box on my system:
>
> The gcc or glibc on my system is hardened (might be true
> for newer gcc/glibc on other systems as well), so it
> actually checks for buffer overflow in 'st
On 8/28/20 11:23 PM, oldk1331 wrote:
> On 8/28/20 9:35 PM, Waldek Hebisch wrote:
>> the hack I proposed is not nice, it is similar to
>> hacks that are probably in use in similar contexts:
>> C compiler have to tolerate access beyond declared
>> size to struct because lot of C code uses it. So
>>
On 8/28/20 9:35 PM, Waldek Hebisch wrote:
> the hack I proposed is not nice, it is similar to
> hacks that are probably in use in similar contexts:
> C compiler have to tolerate access beyond declared
> size to struct because lot of C code uses it. So
> I see no point of going in direction you pro
On Wed, Aug 26, 2020 at 06:08:42PM +0800, oldk1331 wrote:
> On 8/24/20 12:35 AM, Waldek Hebisch wrote:
> > On Sun, Aug 23, 2020 at 10:04:29PM +0800, oldk1331 wrote:
> >> Actually we can stick to hexadecimal for pid
> >> less than 1 million as well.
> >>
> >> Current possible max pid is defined by P
On 8/24/20 12:35 AM, Waldek Hebisch wrote:
> On Sun, Aug 23, 2020 at 10:04:29PM +0800, oldk1331 wrote:
>> Actually we can stick to hexadecimal for pid
>> less than 1 million as well.
>>
>> Current possible max pid is defined by PID_MAX_LIMIT in kernel,
>> which is 2^22, around 4 million.
>
> I wou
On Sun, Aug 23, 2020 at 09:43:48PM +0800, oldk1331 wrote:
> How about encoding PID with 0-9a-zA-Z or some
> other hash method?
>
> If you agree with this approach, I can get to implement it.
For Linux base-64 could work. But if such things is supposed
to serve as Windows filename, then we are li
On Sun, Aug 23, 2020 at 10:04:29PM +0800, oldk1331 wrote:
> Actually we can stick to hexadecimal for pid
> less than 1 million as well.
>
> Current possible max pid is defined by PID_MAX_LIMIT in kernel,
> which is 2^22, around 4 million.
I would not count too much on this limit. I have heard th
Actually we can stick to hexadecimal for pid
less than 1 million as well.
Current possible max pid is defined by PID_MAX_LIMIT in kernel,
which is 2^22, around 4 million.
On Sun, Aug 23, 2020, 8:01 PM Waldek Hebisch
wrote:
> On Sat, Aug 22, 2020 at 10:41:50PM +0800, oldk1331 wrote:
> > Okay, I
How about encoding PID with 0-9a-zA-Z or some
other hash method?
If you agree with this approach, I can get to implement it.
On Sun, Aug 23, 2020, 8:01 PM Waldek Hebisch
wrote:
> On Sat, Aug 22, 2020 at 10:41:50PM +0800, oldk1331 wrote:
> > Okay, I take a different approach and try
> > to worka
On Sat, Aug 22, 2020 at 10:41:50PM +0800, oldk1331 wrote:
> Okay, I take a different approach and try
> to workaround this problem in function
> "make_server_name":
>
> diff --git a/src/lib/sockio-c.c b/src/lib/sockio-c.c
> index 30e0eba5..a168129f 100644
> --- a/src/lib/sockio-c.c
> +++ b/src/lib
Okay, I take a different approach and try
to workaround this problem in function
"make_server_name":
diff --git a/src/lib/sockio-c.c b/src/lib/sockio-c.c
index 30e0eba5..a168129f 100644
--- a/src/lib/sockio-c.c
+++ b/src/lib/sockio-c.c
@@ -857,9 +857,21 @@
int
make_server_name(char *name,char *
On 8/10/20 11:38 AM, oldk1331 wrote:
> Ok, I'll try to test sockaddr_un on mingw32
> and mingw64 then.
I tested in mingw64 on windows, apparently
we use winsock2.h and there's no direct
support for sockaddr_un.
Let me explore other options.
- Qian
--
You received this message because you are s
>
>
> > I mean, if I can build fricas in mingw with this
> > patch (sockaddr_un) successfully, then can this
> > patch be merged? Aka which platform should
> > I test for breakage?
>
> What you mean by "this patch". The patch I posted
> (adding unused field) should not break anything and
> should
On Sun, Aug 09, 2020 at 08:03:09PM +0800, oldk1331 wrote:
> On Sat, Aug 8, 2020, 9:02 PM Waldek Hebisch
> wrote:
>
> > On Sat, Aug 08, 2020 at 04:59:27PM +0800, oldk1331 wrote:
> > > Why do you think Windows needs different
> > > declarations? Aren't we using cygwin/mingw?
> >
> > For that issue
On Sat, Aug 8, 2020, 9:02 PM Waldek Hebisch
wrote:
> On Sat, Aug 08, 2020 at 04:59:27PM +0800, oldk1331 wrote:
> > Why do you think Windows needs different
> > declarations? Aren't we using cygwin/mingw?
>
> For that issue Cygwin, WSL and mingw are really
> different platforms. WSL emulates Linu
On Sat, Aug 08, 2020 at 04:59:27PM +0800, oldk1331 wrote:
> Why do you think Windows needs different
> declarations? Aren't we using cygwin/mingw?
For that issue Cygwin, WSL and mingw are really
different platforms. WSL emulates Linux, so
it should be enough to treat it as Linux. Mingw
uses nati
> Cygwin or mingw or WSL?
What I have heard about WSL2, then it shouldn't be a big problem to
build FriCAS there. Or is is because of the X requirement?
Anyway, if I were interesedt in Windows support, I focus on WSL2.
Ralf
--
You received this message because you are subscribed to the Google G
Why do you think Windows needs different
declarations? Aren't we using cygwin/mingw?
BTW, what's our support status for windows?
Cygwin or mingw or WSL? I tried to build with
Msys2 today, but it's really a bad experience,
very slow, I gave up after 2 hours.
> should work. On Linux theoreticaly
On Sun, Jul 26, 2020 at 06:00:17PM +0800, oldk1331 wrote:
> Hi all,
>
> Today suddenly I can't launch FriCAS, it
> shows "*** buffer overflow detected ***:
> terminated Aborted".
>
> After some debugging, I found that sman
> calls function "open_server" in
> sockio-c.c#929:
>
> strcpy(server[1
Hi all,
Today suddenly I can't launch FriCAS, it
shows "*** buffer overflow detected ***:
terminated Aborted".
After some debugging, I found that sman
calls function "open_server" in
sockio-c.c#929:
strcpy(server[1].addr.u_addr.sa_data, name);
"sa_data" is char[14], and "name" is
"/tmp/.i"+ge
47 matches
Mail list logo
