Re: Thread-local storage issues arose again? Firefox frequently crashes on 10.0 aarch64
On Sun, Apr 14, 2024 at 05:15:31AM +, Emmanuel Dreyfus wrote: > On Sun, Apr 14, 2024 at 02:07:26PM +0900, PHO wrote: > > As I mentioned in > > http://mail-index.netbsd.org/netbsd-users/2024/04/12/msg030915.html, Firefox > > tab processes crash very frequently on NetBSD/aarch64 10.0. Building it with > > PKG_OPTIONS.firefox+=debug-info revealed that when it crashes it segfaults > > at one of these two places non-deterministically: > > Hello > > Not sure it is related, but it could be: I get random SISEGV when > bulk-building NetBSD-10.0/i386 packages on NetBSD-10.0/amd64 XEN3_DOMU. I also get theses SISEGV on bare-metal amd64 (it's a i9 with 20 cores) when running builds with high paralelism (packages or build.sh). And I also get these firefox crashes. As I've not yet seens the SISEGV on Xen yet I suspected a hardware issue, But if others are seeing it too a software bug becomes more likely -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: short reads on unix stream on netbsd-10
On Wed, Sep 06, 2023 at 09:28:31AM -0400, Mouse wrote:
> > serv_input: read@3 need 468 got 396 (and disconnects).
>
> > The code is:
> > if (i != (nchars = read(fd, T.c, i))) {
> > fprintf(stderr, "serv_input: read@%d need %d got %d\n",
> > fd, i, nchars);
> > server_died();
> > }
>
> > fd 3 is a unix stream socket
> > I didn't find any place where this file descriptor could have been
> > put to nonblocking.
>
> > I could wrap the read in a loop to work around this, but I wonder if
> > it's expected behavior to get short reads in this case ?
>
> That's a good question. In general, SOCK_STREAM socket connections
> never promise atomicity of anything larger than one byte. It's
> possible AF_LOCAL provides a stronger promise, but, if so, I'm not sure
> where that promise is documented, or how widespread it is.
>
> As for it being _expected_ behaviour...I wouldn't call it "expected",
> exactly, but I would call it "not particularly surprising".
>
> So, I'd say the code you quote is at fault here.
thanks. I remplaced the read with a poll()/read() loop; this fixes the issue.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
short reads on unix stream on netbsd-10
Hello
I upgraded a server from -8 to -10, and now rtty complains on heavy
traffic:
serv_input: read@3 need 468 got 396 (and disconnects).
The code is:
if (i != (nchars = read(fd, T.c, i))) {
fprintf(stderr, "serv_input: read@%d need %d got %d\n",
fd, i, nchars);
server_died();
}
fd 3 is a unix stream socket
I didn't find any place where this file descriptor could have been put to
nonblocking.
I could wrap the read in a loop to work around this, but I wonder if it's
expected behavior to get short reads in this case ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Re: new certificate stuff
On Sun, Aug 27, 2023 at 10:53:58PM +, Taylor R Campbell wrote: > > Date: Sat, 26 Aug 2023 19:15:01 +0200 > > From: Manuel Bouyer > > > > On Sat, Aug 26, 2023 at 04:48:59PM +, Taylor R Campbell wrote: > > > [...] > > > If you currently use security/mozilla-rootcerts or > > > security/ca-certificates (or security/mozilla-rootcerts-openssl) to > > > populate /etc/openssl/certs, and you want to continue to use it, you > > > will have to put the line `manual' in /etc/openssl/certs.conf before > > > you next run postinstall(8). > > > > Will postinstall remove any certificate in /etc/openssl/certs/ > > if there is no certs.conf ? I have server certificates here, in addition > > to some local (private) CA roots. > > Currently, if /etc/openssl/certs.conf doesn't exist, `certctl rehash' > (the crux of `postinstall fix opensslcerts') will print an error > message and then exit with status 0. This combination is a bug -- > need to think a bit about it, but probably better to exit nonzero than > to suppress the error message. Yes, it's fine to error out in this case > > So if you unpack new _non-etc_ sets, `postinstall fix' won't > clobber your /etc/openssl/certs directory. > > The etc.tgz set, however, will have /etc/openssl/certs.conf. So if > you naively unpack etc.tgz, `postinstall fix' will clobber your > /etc/openssl/certs directory. As it will clobber others /etc/ files, so that's fine. > > That said, I think if you use etcupdate(8), it will interactively > prompt you before creating the new /etc/openssl/certs.conf. (Have > made a note to add this in my etcmerge(8) tool to do a three-way merge > for updating (x)etc sets too.) > > I'm open to other suggestions about how to handle the transition from > manually maintained /etc/openssl/certs on (say) 9.x with no certs.conf > or certctl(8) to 10.0 with new default certs.conf and certctl(8), > provided that > > (a) new installations get /etc/openssl/certs populated out of the box, > > and > > (b) on _future_ updates (like 10.0 to 10.1, where both releases have > certctl(8) and a default certs.conf), /etc/openssl/certs gets > updated too (unless you set `manual' in /etc/openssl/certs.conf). Maybe postinstall should check the /etc/openssl/certs.conf existance, and fail the 'fix opensslcerts' asking for it to be manually created; as we do for e.g. uid/gid if some are missing ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: new certificate stuff
On Sat, Aug 26, 2023 at 04:48:59PM +, Taylor R Campbell wrote: > [...] > If you currently use security/mozilla-rootcerts or > security/ca-certificates (or security/mozilla-rootcerts-openssl) to > populate /etc/openssl/certs, and you want to continue to use it, you > will have to put the line `manual' in /etc/openssl/certs.conf before > you next run postinstall(8). Will postinstall remove any certificate in /etc/openssl/certs/ if there is no certs.conf ? I have server certificates here, in addition to some local (private) CA roots. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: style(5) proposal: forbid extern in .c
On Wed, Mar 15, 2023 at 11:23:05AM +, Taylor R Campbell wrote: > Proposal: Forbid extern declarations in .c files. > > extern declarations in .c files invite easily avoided bugs where the > definition and use have mismatched types, because the compiler doesn't > have an opportunity to check them. Fix: Always put the extern > declaration in a .h file shared by the .c file defining it and the .c > files using it. > > Pretty simple. Any objections? Maybe an exception could be made for functions defined in an assembly file and used from a single C file ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: brandelf(1)
On Wed, Jan 19, 2022 at 11:15:50AM +0100, Hauke Fath wrote: > On Tue, 18 Jan 2022 20:33:47 - (UTC), Christos Zoulas wrote: > >> > >> Since it is such a niche tool, I would add it to pkgsrc (but base doesn't > >> hurt much either). > > > > I think that if FreeBSD has it in base, we should too to avoid POLA > > and since it is small, it does not matter much. > > Is it even relevant without installing the suse* packages? Are there > static linux binaries these days? Yes, the binaries on which I had to use brandelf are static: xc8/v2.35/bin/xc8: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, stripped xc8/v2.35/bin/xc8.orig:ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
brandelf(1)
Hello, so, to be able to run linux binaries with don't have the Linux type in its ELF header, I have ported FreeBSD's brandelf(1): https://www.unix.com/man-page/freebsd/1/brandelf/ brandelf -- mark an ELF binary for a specific ABI Should it go in base, or pkgsrc (or nowhere, it's not usefull enough) ? It's very small - a single C file of 216 lines (including comments), the binary is 9.1K. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Anyone still using YP support on NetBSD?
On Thu, Sep 23, 2021 at 02:06:51PM -0700, Jason Thorpe wrote: > Anyone? I do -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Waiting for Randot (or: nia and maya were right and I was wrong)
On Fri, Jan 15, 2021 at 12:21:24AM +, Taylor R Campbell wrote: > > Date: Thu, 14 Jan 2021 13:21:58 +0100 > > From: Manuel Bouyer > > > > On Thu, Jan 14, 2021 at 10:15:41AM +, nia wrote: > > > I still think my idea to record a second of noise from /dev/audio on > > > machines that totally lack other strong sources is a good one. We did > > > already put together the code and test it on a range of hardware and > > > VMs. > > > > And what about systems that don't have a /dev/audio (or system that have > > play-only /dev/audio) ? > > What about them? Systems without usable microphone noise are no worse > off than they would have been without nia's suggestion. > > If a machine doesn't have any unpredictable inputs, well, there's no > magic we can do -- you can copy a seed over from another machine (on a Yes. I just want to make sure this will remain an option. For this to work the machine has to come up multiuser with working network ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: tolower()/islower() and char
On Thu, Jan 14, 2021 at 12:52:06PM +0100, Martin Husemann wrote: > On Thu, Jan 14, 2021 at 12:28:57PM +0100, Manuel Bouyer wrote: > > Does the standard explicitely state that the value should either be > > EOF or >= 0 ? > > Yes, Section 7.4 paragrah 1 second sentence (ISO C 2018): > > > In all cases the argument is an int, the value of which shall be > > representable as an unsigned char or shall equal the value of the > > macro EOF. If the argument has any other value, the behavior is > > undefined. > thanks. I have enough to reply to Xen's devs. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Waiting for Randot (or: nia and maya were right and I was wrong)
On Thu, Jan 14, 2021 at 10:15:41AM +, nia wrote: > [...] > I still think my idea to record a second of noise from /dev/audio on > machines that totally lack other strong sources is a good one. We did > already put together the code and test it on a range of hardware and > VMs. And what about systems that don't have a /dev/audio (or system that have play-only /dev/audio) ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: tolower()/islower() and char
On Thu, Jan 14, 2021 at 12:19:39PM +0100, Martin Husemann wrote: > On Thu, Jan 14, 2021 at 12:14:28PM +0100, Manuel Bouyer wrote: > > Any comment about this ? I'm not familiar with these details ... > > man ctype and search for CAVEATS thanks. So NetBSD and glibc took different approach to try to avoid undefined behavior. I am right saying that both are standard-compliant ? Does the standard explicitely state that the value should either be EOF or >= 0 ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
tolower()/islower() and char
Hello, In xentools, we have patches like -if (tolower(*s) != tolower(*se)) +if (tolower((unsigned char)*s) != tolower((unsigned char)*se)) (s and se being char*) This is to fix «array subscript has type 'char' [-Werror=char-subscripts]» I submitted this to Xen, and a developper asks: > Isn't this something that wants changing in your ctype.h instead? > the functions (or macros), as per the C standard, ought to accept > plain char aiui, and if they use the input as an array subscript, > it should be their implementation suitably converting type first. Any comment about this ? I'm not familiar with these details ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
enabling ldap for racoon ?
Hello
I did spend some time to improve the ldap support in racoon(8).
It's now working fine for me.
Would anyone object enabling ldap support by default ?
See attached patch
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Index: Makefile
===
RCS file: /cvsroot/src/usr.sbin/racoon/Makefile,v
retrieving revision 1.35
diff -u -p -u -r1.35 Makefile
--- Makefile1 Apr 2018 23:00:40 - 1.35
+++ Makefile25 Nov 2020 18:16:46 -
@@ -58,6 +58,12 @@ CPPFLAGS+=-DHAVE_OPENSSL_IDEA_H
CPPFLAGS+=-DINET6
.endif
+.if (${USE_LDAP} != "no")
+CPPFLAGS+=-DHAVE_LIBLDAP
+LDADD+=-lldap
+DPADD+= ${LIBLDAP}
+.endif
+
LDADD+= -lcrypto -lcrypt
DPADD+= ${LIBIPSEC} ${LIBCRYPT}
Re: Solving the syslogd problem
On Tue, Jan 28, 2020 at 11:13:38PM +, David Brownlee wrote: > A variant would be to have syslog in /sbin and have a way to nudge it > later in startup to load a shared library from usr/lib which includes > all the network code... But I would prefer your syslogd + > syslogd-network split :) +1 -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: dlopen() and -pg
On Tue, Nov 26, 2019 at 06:14:37PM +0100, Joerg Sonnenberger wrote: > devel/gperftools? thanks. From first tests, it seems to have trouble building call graphs, and decoding library function names, but I'll keep experimenting. Maybe it'll give something usefull. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: dlopen() and -pg
On Tue, Nov 26, 2019 at 03:24:20PM +0100, Joerg Sonnenberger wrote: > On Tue, Nov 26, 2019 at 03:18:03PM +0100, Manuel Bouyer wrote: > > trying to profile a c++ program which uses dlopen and pthreads (opencpn, > > FWIW), > > I'm not surprised at all. -pg will only work reliable with -static. And I can't link statically, as it depends on libraries that are only available as .so. Is there some other profiling tools working on NetBSD ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
dlopen() and -pg
Hello, trying to profile a c++ program which uses dlopen and pthreads (opencpn, FWIW), I get a core dump: Program received signal SIGSEGV, Segmentation fault. 0x006fb040 in dl_iterate_phdr () (gdb) where #0 0x006fb040 in dl_iterate_phdr () #1 0x006fd7d0 in __libc_static_tls_setup () #2 0x007d5d20 in _libc_init () #3 0x7bb33844 in _rtld_call_function_void (obj=0x6d42c000, addr=8215716) at /usr/src/libexec/ld.elf_so/rtld.h:488 #4 _rtld_call_initfini_function (obj=0x6d42c000, mask=, func=8215716) at /usr/src/libexec/ld.elf_so/rtld.c:143 #5 _rtld_call_init_function (cur_objgen=, mask=, obj=0x6d42c000) at /usr/src/libexec/ld.elf_so/rtld.c:258 #6 _rtld_call_init_functions (mask=mask@entry=0x7ffd4480) at /usr/src/libexec/ld.elf_so/rtld.c:316 #7 0x7bb3442c in _rtld (sp=, relocbase=) at /usr/src/libexec/ld.elf_so/rtld.c:782 #8 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #9 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #10 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #11 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #12 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #13 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #14 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #15 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so [...] (here it seems to be looping on _rtld_start(), but it may be a debugger issue). This is on 9.0_BETA; the above stack trace is on earmv7hf but I get the same on x86_64. A hello world c++ program works as expected Any idea ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
own memory usage ?
Hello, I'm porting a software which manages its own cache, and the cache mamangement wants to know how much memory it's currently using. Do we have a way to get, from malloc(3) or from the kernel, to get self memory usage ? Any example I could use ? AFAIK getrusage(2) doesn't give us instant memory usage but only statistics from the start of the process. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: colorls in base
On Fri, Feb 15, 2019 at 10:51:05AM -0800, Alistair Crooks wrote: > > Actually, colorized texts do things worse for me, because by highlingting > > some thing it prevents me from seeing other important things. > > > > Of course, but sane highlighting of things, rather than explosions in a > paint factory like some syntax coloring schemes I've seen in editors, is The problem is, "sane highlighting" actually depends on what't your looking for in a file; just defining it by file type doesn't work so well. When you're looking at a C program you're not looking at only variables, or only strings. You need to read all characters of it. All in all, I find a monochrome text (with a single font too) much easier to read. > the goal. In that way, your eyes are drawn to things that matter. In the > colored ls script I posted, normal, everyday regular files are left > untouched by colouring. Anything executable is in red (none of that > straining to see a '*' on the end) and then, it will make things worse if I'm looking for a file which is not executable. > > > > The point is that the warning lights are usually off. > > > > Indeed. And if you're not alarmed when they're on, that's a problem. I am and that's the goal. But if there were bright red lights showing up every now and then, I wouldn't notice the alarms any more. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: colorls in base
On Fri, Feb 15, 2019 at 02:20:05PM -, Christos Zoulas wrote: > > All this color discussion made me think: > > The kernel is already using green, and recently we added "autoconfiguration > error" to highlight errors. Shouldn't we (in addition) make those lines red? please no. I have autoconfig errors in my kernels boot that are expected, and if they were red it would make reading other message harder. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: colorls in base
On Thu, Feb 14, 2019 at 06:26:29PM -0800, John Nemeth wrote: > On Feb 15, 10:56am, Rin Okuyama wrote: > } > } I'd like to propose to introduction -G (colorized output) option > } to ls(1), which is compatible to FreeBSD and macOS: > } > } http://www.netbsd.org/~rin/colorls-20190215.patch > } > } I know that we already have misc/colorls in pkgsrc. In the era of > > -1 we don't need this kind of annoying crap in base. seconded. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: deleting telnet/telnetd
On Wed, Dec 19, 2018 at 11:48:49PM +, David Holland wrote: > If you value your sanity, don't. But, also, you might want to rethink > how much you trust it. As much as the network I run it on. If someone can do a MITM on this network I have a much bigger problem than a telnet exploit. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: deleting telnet/telnetd
On Wed, Dec 19, 2018 at 10:03:19PM +, David Holland wrote: > On Wed, Dec 19, 2018 at 10:58:14PM +0100, Manuel Bouyer wrote: > > On Wed, Dec 19, 2018 at 09:03:27PM +, David Holland wrote: > > > [...] > > > The hope, I think, was that the conclusion would be that we don't > > > really need one. > > > > We really need one, and the one we have does the job. I really don't see > > why we shoud rewrite something that works. > > Have you looked at the code? no but I do use it quite often. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: deleting telnet/telnetd
On Wed, Dec 19, 2018 at 09:03:27PM +, David Holland wrote: > [...] > The hope, I think, was that the conclusion would be that we don't > really need one. We really need one, and the one we have does the job. I really don't see why we shoud rewrite something that works. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Moving telnet/telnetd from base to pkgsrc
On Thu, Dec 13, 2018 at 10:50:30PM +, co...@sdf.org wrote: > Hi, > > telnet: > 1. terrible code, with many abstraction violations > 2. something people expect to talk to their legacy machines, which > nobody but them has access to. > 3. common use case is served by netcat, already in base. > 4. too much superfluous functionality. > > Let's pull it out as a package, the alternative being breaking > functionality for the four remaining users. Actually, lots of mananged network equipements (or remote management boards) can talk telnet. It still has its use. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: adding stuff to the base installation to make user experience better
On Thu, Jul 06, 2017 at 09:34:08PM +0530, Utkarsh Anand wrote: > | for example people usally need $EDITOR other than vi/ed > > Has vi ever worked for anyone (in NetBSD)? I don't use anything but NetBSD's vi (I even install it on linux) -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --
Re: C tty/tcsetattrs question
On Thu, May 26, 2016 at 07:30:05PM +0200, Manuel Bouyer wrote: > Hello, > I have a GPS device connected to a serial port. It defaults to 9600bps > NMEA messages, but I need to switch it to 4800bps. There are NMEA > commands for this, and I can properly do this using cu(1). > > Now I'm trying to write a program to do this at boot time. > First I need to determine if the GPS is outputting at 4800 or 9600bps > (the CPU may be rebooted, or even powered off wihout resetting the GPS > module). > I wrote the attached C program, but the cfsetspeed() doesn't seem > to have any effect: with the GPS running at 9600bps, > if I start with the tty set to 9600 (for example from a previous > cu(1) run) I get proper NMEA sentences on both check_term() calls, > and if I start with the tty set to 4800 (e.g. from a previous > cu(1) run) I get either nothing or garbage (not getting anything > from the tty is a valid case, as the tty is in canon mode select() > will return a read event only if the serial port got something that > looks like a line). > > Does anyone see an obvious error or something I missed ? Ops, I used = where I wanted &=. This resulted in non-wanted flags in various place, with strange effects. With this fixed the speed settings have more effects. Now there are bugs in the driver itself (or in the allwiner serial port) but this is another problem. -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --
Re: C tty/tcsetattrs question
On Fri, May 27, 2016 at 03:37:03AM +, David Holland wrote: > On Thu, May 26, 2016 at 07:30:05PM +0200, Manuel Bouyer wrote: > > I have a GPS device connected to a serial port. It defaults to 9600bps > > NMEA messages, but I need to switch it to 4800bps. There are NMEA > > commands for this, and I can properly do this using cu(1). > > > > Now I'm trying to write a program to do this at boot time. > > First I need to determine if the GPS is outputting at 4800 or 9600bps > > (the CPU may be rebooted, or even powered off wihout resetting the GPS > > module). > > I wrote the attached C program, but the cfsetspeed() doesn't seem > > to have any effect: with the GPS running at 9600bps, > > if I start with the tty set to 9600 (for example from a previous > > cu(1) run) I get proper NMEA sentences on both check_term() calls, > > and if I start with the tty set to 4800 (e.g. from a previous > > cu(1) run) I get either nothing or garbage (not getting anything > > from the tty is a valid case, as the tty is in canon mode select() > > will return a read event only if the serial port got something that > > looks like a line). > > > > Does anyone see an obvious error or something I missed ? > > No, but some things to check: > > (1) When you have this program change the speed, does the speed change > register? If you call tcgetattr right after, what's the speed > returned? And what do you see if if you use stty? stty returns the expected speed, so I guess the kernel has the right speed. But this may be cached somewhere; I'll add some debug printf in the com driver to make sure. > > (2) Is the behavior different if you specify TCSANOW instead of TCSAFLUSH? > (It shouldn't be, but...) will try. > > (3) why are you turning on ICANON? Because NMEA is a line-oriented protocol, so having select() wake up when a whole line is ready to be read is easier to deal with. But for test I could run with ICANON off. -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --
C tty/tcsetattrs question
Hello,
I have a GPS device connected to a serial port. It defaults to 9600bps
NMEA messages, but I need to switch it to 4800bps. There are NMEA
commands for this, and I can properly do this using cu(1).
Now I'm trying to write a program to do this at boot time.
First I need to determine if the GPS is outputting at 4800 or 9600bps
(the CPU may be rebooted, or even powered off wihout resetting the GPS
module).
I wrote the attached C program, but the cfsetspeed() doesn't seem
to have any effect: with the GPS running at 9600bps,
if I start with the tty set to 9600 (for example from a previous
cu(1) run) I get proper NMEA sentences on both check_term() calls,
and if I start with the tty set to 4800 (e.g. from a previous
cu(1) run) I get either nothing or garbage (not getting anything
from the tty is a valid case, as the tty is in canon mode select()
will return a read event only if the serial port got something that
looks like a line).
Does anyone see an obvious error or something I missed ?
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
#include
#include
#include
#include
#include
#include
#include
struct termios orig_t;
int term_fd = -1;
static void
exit_handler(void)
{
if (term_fd >= 0) {
tcsetattr(term_fd, TCSAFLUSH, _t);
}
}
static void
sig_hanlder(int sig)
{
exit_handler();
exit(1);
}
static int
check_term(int fd)
{
fd_set rset;
struct timeval timeout;
int tries = 10;
int ret;
char buf[100];
FILE *f = fdopen(fd, "r");
if (f == NULL) {
err(EXIT_FAILURE, "fdopen() failed");
}
while (tries > 0) {
FD_ZERO();
FD_SET(fd, );
timeout.tv_sec = 1;
timeout.tv_usec = 0;
ret = select(fd + 1, , NULL, NULL, );
switch(ret) {
case -1:
err(EXIT_FAILURE, "select() failed");
break;
case 0:
printf("timeout %d\n", tries);
tries--;
break;
default:
if (FD_ISSET(fd, )) {
if (fgets(buf, sizeof(buf), f) != NULL) {
printf("got: -- %s --\n", buf);
if (strncmp(buf, "$GP", 3) == 0) {
return 1;
}
}
tries--;
}
}
}
return 0;
}
int
main(int argc, const char *argv[])
{
static struct termios working_t;
if (argc != 2) {
fprintf(stderr, "usage: %s \n", argv[0]);
exit(1);
}
term_fd = open(argv[1], O_RDWR, 0);
if (term_fd < 0) {
fprintf(stderr, "open %s: %s\n", argv[1], strerror(errno));
exit(1);
}
if (tcgetattr(term_fd, _t) < 0) {
perror("tcgetattr");
exit(1);
}
atexit(exit_handler);
signal(SIGINT, sig_hanlder);
signal(SIGTERM, sig_hanlder);
working_t = orig_t;
#if 0
working_t.c_iflag =~ (IGNBRK | IXON | IXOFF | IMAXBEL);
working_t.c_iflag |= IGNCR;
#endif
working_t.c_iflag = 0;
working_t.c_oflag =~ (OPOST);
working_t.c_cflag =~ (CSIZE | CSTOPB | PARENB | CRTSCTS | MDMBUF);
working_t.c_cflag |= CS8 | CLOCAL;
working_t.c_lflag = ICANON | NOKERNINFO;
again:
printf("test 4800\n");
if (cfsetspeed(_t, B4800) != 0)
err(EXIT_FAILURE, "setting speed to 4800");
if (tcsetattr(term_fd, TCSAFLUSH, _t) != 0) {
perror("tcsetattr 1");
exit(1);
}
if (check_term(term_fd)) {
printf("already at 4800\n");
}
printf("test 9600\n");
if (cfsetspeed(_t, B9600) != 0)
err(EXIT_FAILURE, "setting speed to 9600");
if (tcsetattr(term_fd, TCSAFLUSH, _t) != 0) {
perror("tcsetattr 2");
exit(1);
}
if (check_term(term_fd)) {
printf("switch to 4800\n");
}
goto again;
}
Re: PaX MPROTECT gdb and software breakpoints
On Sat, May 21, 2016 at 04:21:45PM -0400, Christos Zoulas wrote: > > Hello, > > Now that PaX MPROTECT is the default on 3 platforms (amd64, i386, and evbarm) > the problem of software breakpoints and gdb has surfaced. Namely if MPROTECT > is on, and you try to set a breakpoint you get: > > (gdb) break main > Breakpoint 1 at 0x107e0: file aslr.c, line 8. > (gdb) r > Starting program: /u/christos/a.out > Warning: > Cannot insert breakpoint 1. > Cannot access memory at address 0x107e0 > Cannot insert breakpoint -1. > Temporarily disabling shared library breakpoints: > breakpoint #-1 > > > Gdb tries to write the breakpoint instruction in the text segment, > uvm_io() calls uvm_map_extract(... | UVM_EXTRACT_FIXPROT), but the > max protection for the text segment does not allow writes anymore. > > There are three solutions I can think of (maybe you can think of a better > one): > > 1. Leave it as it is and document that people will have to paxctl +m >the executables that they need to mprotect before they can debug >it. > 2. create a uvm_io1() and a new UVM_EXTRACT that breaks MPROTECT and >fetches with the right mappings. I don't like that, it breaks MPROTECT >and uvm contracts. But it has the advantage of working on already >started process we PT_ATTACH to. > 3. when process is execed and is already traced (PT_TRACE_ME), disable >MPROTECT. This should work with processes started from gdb, but >not attached ones. We will still need to explain that to attach >and insert breakpoints you need to set MPROTECT off. > > Opinions? I occasionally need to gdb-attach to a running process (usually a daemon) to try to understand what's going on. I think it's important to keep the ability to attach to a running process, which has not been started in a specific way before. -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --
