Re: seawasp failing, maybe in glibc allocator - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: seawasp failing, maybe in glibc allocator
Date
Msg-id alpine.DEB.2.22.394.2105122028010.1107467@pseudo
Whole thread Raw
In response to Re: seawasp failing, maybe in glibc allocator  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: seawasp failing, maybe in glibc allocator
List pgsql-hackers
> Possibly I have just added "ulimit -c unlimited" in the script, we should see 
> the effect on next round.

for def5b065 it ended on on the contrib ltree test:

  2021-05-12 20:12:52.528 CEST [3042602:410] pg_regress/ltree LOG: disconnection: session time: 0:00:13.426
user=buildfarm database=contrib_regression_ltree host=[local]
 

  /home/fabien/pg/build-farm-12/buildroot/HEAD/pgsql.build/contrib/ltree/results/ltree.out
  2021-05-12 20:12:52.523330311 +0200
  @@ -7931,11 +7931,8 @@
   (1 row)

   SELECT count(*) FROM _ltreetest WHERE t ~ '1.1.1.*' ;
  - count
  --------
  -    19
  -(1 row)
  -
  +ERROR:  stack depth limit exceeded
  +HINT:  Increase the configuration parameter "max_stack_depth" (currently  2048kB), after ensuring the platform's
stackdepth limit is adequate.
 
   SELECT count(*) FROM _ltreetest WHERE t ~ '*.1' ;
    count
   -------

Not a core dump, though.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Some other CLOBBER_CACHE_ALWAYS culprits
Next
From: David Steele
Date:
Subject: Always bump PG_CONTROL_VERSION?