segv in p11_array_push

Patrick Welche prlw1 at cam.ac.uk
Fri Jul 13 11:07:02 UTC 2018


On Fri, Jul 13, 2018 at 10:37:11AM +0100, Patrick Welche wrote:
> On Mon, Jul 09, 2018 at 02:51:02PM +0200, Daiki Ueno wrote:
> > Patrick Welche <prlw1 at cam.ac.uk> writes:
> > 
> > > On Mon, Jul 09, 2018 at 09:53:39AM +0200, Daiki Ueno wrote:
> > >> Could you give us a bit more information, e.g., which operating system
> > >> you are running, and what are there in the complete backtrace?
> > >
> > > Sorry for having forgotten the trace!
> > > - and libsoup is 2.62.2
> > 
> > Thank you, but you still didn't answer which operating system you are
> > running.  According to the hint "(using pkgsrc.org)", I am guessing you
> > are running some version of NetBSD, right?
> 
> Correct (8.99.21/amd64)
>  
> > Is reallocarray implemented there?
> 
> Apparently so, but I think you are right to query this...
> 
> autoconf test passes: checking for reallocarray... yes
> 
> # nm -g /lib/libc.so | grep reallocarray
> 00000000000451a0 T reallocarray
> 
> but oddly, in /usr/include/stdlib.h:
> 
> #ifdef _OPENBSD_SOURCE
> long long strtonum(const char *, long long, long long, const char **);
> void    *reallocarray(void *, size_t, size_t);
> #endif

Building p11-kit with -D_OPENBSD_SOURCE prevents the coredump on NetBSD,
which is good enough for me - thanks for the hole-in-one analysis!

It seems from

  https://mail-index.netbsd.org/tech-userlevel/2015/02/05/msg008912.html

that the obfuscation is to encourage reallocarr(3) instead. The point
is that as reallocarray is in libc, it always will be, and AC_CHECK_LIBS
will always find it.

I suppose I could make a AC_CHECK_LIBS(reallocarr) patch for you, and
use that if found, else use reallocarray. What do you think?


Thanks,

Patrick


More information about the p11-glue mailing list