Re: OSX doesn't accept identical source/target for strcpy() anymore
От | Andres Freund |
---|---|
Тема | Re: OSX doesn't accept identical source/target for strcpy() anymore |
Дата | |
Msg-id | 20131028194609.GA16709@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: OSX doesn't accept identical source/target for strcpy() anymore (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: OSX doesn't accept identical source/target for strcpy() anymore
|
Список | pgsql-hackers |
On 2013-10-28 15:20:20 -0400, Andrew Dunstan wrote: > > On 10/28/2013 02:26 PM, Andres Freund wrote: > > > >It'd be neat if we could get a buildfarm animal up that uses valgrind - > >which would catch such and lots of other errors. That's where the topic > >has come up in the past: > >http://www.postgresql.org/message-id/20110312133224.GA7833%40tornado.gateway.2wire.net > >http://www.postgresql.org/message-id/20130217142209.GA5073@awork2.anarazel.de > > > > > How exactly is it going to do that? The easiest method - somewhat slower than necessary - is to just run "valgrind --suppressions=$srcdir/src/tools/valgrind.supp make check". But the buildfarm supports running a postgres install before installcheck, right? If we could run just that step using valgrind we'd be very well of I think because we'd not run valgrind (slow!) if there are plain regression failures around. [.. looking for sources ...] start_db in https://github.com/PGBuildFarm/client-code/blob/master/run_build.pl is where the server's run, right? Hm. That uses pg_ctl and not the server itself and relies on pg_ctl -w returning when the server is started... So it's not easy to make it use valgrind properly. We could hack it by replacing bin/postgres with a wrapper around valgrind that invokes postgres, but ick. Maybe we can make pg_ctl start $PG_POSTGRES_BINARY instead of postgres if defined? Better ideas? > Fundamentally, the buildfarm client is simply glue to run existing build and > test code, collect the results, and send them to the server. AFAICT there > are no configure or make targets for running under valgrind. > If someone provides the requisite support in the build system for this I'll > be happy to add buildfarm support for it. It'd be relatively easy to add support for make check (not installcheck) wrapping postgres in valgrind via pg_regress, but I am not sure that's the best way to go. I think defining an additional CFLAG (USE_VALGRIND) shouldn't be a problem? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: