Re: Binutils objcopy bug (was Re: rebase segfault)
On 03/05/2013 12:42 AM, marco atzeri wrote: On 3/4/2013 11:32 PM, Andrew Dunstan wrote: Incidentally, there is no need to change the test schedules, and such a patch would not be accepted. There is an option to restrict the number of concurrent connections the regression tests will run (designed specifically with Cygwin in mind, in fact, many years ago.) The way to do this is: make MAX_CONNECTIONS=10 check nice to know. The test.patch is what I used in last release Please note that prepared_xacts is freezing the test sequence so i am forced to skip it , for the time being Yeah. Now that's an interesting thing, which I have also seen. Here's a relevant data point. My Postgresql Buildfarm member brolga http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=brolgabr=HEAD, which runs on Cygwin 1.7.7, and builds with gcc 4.3.4, doesn't have this difficulty. So What I'd like to know is what changed between when those things were released and now to make this break. cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Binutils objcopy bug (was Re: rebase segfault)
On 01/30/2013 11:46 AM, Andrew Dunstan wrote: On 01/29/2013 05:30 PM, Reini Urban wrote: On Sat, Jan 26, 2013 at 1:52 AM, marco atzeri wrote: On 1/26/2013 7:32 AM, Reini Urban wrote: rebase is not to blame. I agree ;-) Someone else is incorrectly managing the reloc table, and also objcopy seems innocent ... Postgresql dll's are built in this way: My strong guess is dllwrap. No other packages uses the ancient dllwrap anymore. I tried to get rid of it, but got stuck somewhere else. Hi Reini, I agree dllwrap seems the coolprit, and gcc -shared seems a better alternative, at least on a single test with this dll. I looked on the postgresql makefiles and it is a big mess to replace dllwrap; upstream is crazy, they crippled configure forcing a specific version and refusing to use Automake. Autoconf+Automake will be a much cleaner approach, and will allow to avoid at all the platform checks. Yes, I had the same impression but it is unfortunately not realistic. I worked against dllwrap removal but got stuck somewhere. When I find my old patches I'll hand it over to you. Just came back from holidays. I will be very happy to work with you to remove the use of dllwrap etc. for cygwin. Since I'm a Postgres committer (and the only one interested in Cygwin at all) I'm in a good position to do this. I believe the Postgres project had problems in the past with automake and made a decision long ago not to use it, so we're not going down that route. However, that surely need not stop us from getting this working. I have not heard a word on this in the 5 weeks or so since it was sent. Are you guys interested in fixing this or not? cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Binutils objcopy bug (was Re: rebase segfault)
On 03/04/2013 04:30 PM, marco atzeri wrote: On 3/4/2013 9:00 PM, Andrew Dunstan wrote: I have not heard a word on this in the 5 weeks or so since it was sent. Are you guys interested in fixing this or not? yes Andrew, I am working on it, unfortunately this Makefile spaghetti is not nice to handle Well, you can ask me for help :-) I deal with this code a lot. Anyway, I'll take a look at what you have so far. cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Binutils objcopy bug (was Re: rebase segfault)
On 03/04/2013 04:30 PM, marco atzeri wrote: On 3/4/2013 9:00 PM, Andrew Dunstan wrote: I have not heard a word on this in the 5 weeks or so since it was sent. Are you guys interested in fixing this or not? yes Andrew, I am working on it, unfortunately this Makefile spaghetti is not nice to handle probably 90% is working now, but I just found that postgres.exe is incomplete attached current patch for my trial src/backend/Makefile needs some works for postgres.exe and libpostgres.a that I hope is the only missing bit Incidentally, there is no need to change the test schedules, and such a patch would not be accepted. There is an option to restrict the number of concurrent connections the regression tests will run (designed specifically with Cygwin in mind, in fact, many years ago.) The way to do this is: make MAX_CONNECTIONS=10 check cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Binutils objcopy bug (was Re: rebase segfault)
On 01/29/2013 05:30 PM, Reini Urban wrote: On Sat, Jan 26, 2013 at 1:52 AM, marco atzeri wrote: On 1/26/2013 7:32 AM, Reini Urban wrote: rebase is not to blame. I agree ;-) Someone else is incorrectly managing the reloc table, and also objcopy seems innocent ... Postgresql dll's are built in this way: My strong guess is dllwrap. No other packages uses the ancient dllwrap anymore. I tried to get rid of it, but got stuck somewhere else. Hi Reini, I agree dllwrap seems the coolprit, and gcc -shared seems a better alternative, at least on a single test with this dll. I looked on the postgresql makefiles and it is a big mess to replace dllwrap; upstream is crazy, they crippled configure forcing a specific version and refusing to use Automake. Autoconf+Automake will be a much cleaner approach, and will allow to avoid at all the platform checks. Yes, I had the same impression but it is unfortunately not realistic. I worked against dllwrap removal but got stuck somewhere. When I find my old patches I'll hand it over to you. Just came back from holidays. I will be very happy to work with you to remove the use of dllwrap etc. for cygwin. Since I'm a Postgres committer (and the only one interested in Cygwin at all) I'm in a good position to do this. I believe the Postgres project had problems in the past with automake and made a decision long ago not to use it, so we're not going down that route. However, that surely need not stop us from getting this working. cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sshd
Steven Collins wrote: Before 1.7.x came out I had sshd working under cygwin. After upgrading it stopped working. I investigated and found the hosts.allow file and made the recommended change there. That got my server working to the point where I can ssh localhost and see the hungry-hungry-hippo. :) When I try to ssh into the same computer using its real-world IP number/name it get ssh: connect to host read.host.name port 22: Connection refused. Any suggestions on where to go from here? What are the Listen_Address and Port settings in the config file? cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: psql setsid error
Reini Urban wrote: Gary . schrieb: psql: FATAL: setsid() failed: Operation not permitted Hmm, known problem. I'll change it like sed --in-place -e's/#define HAVE_SETSID 1/#undef HAVE_SETSID/' \ src/include/pg_config.h This is completely the wrong thing to do. pg_config.h is an autogenerated file. If anything, it should go in pg_config_manual.h, but much better would be to fix the configure check, if it's wrong. Just hacking the config files is a losing game. Butr why does it fail anyway? It works just fine on the PostgreSQL Buildfarm. See http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=brown_batdt=2010-05-09%20183006stg=config cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: PostgreSQL plperl crash on Cygwin 1.7.5
Reini Urban wrote: 2010/5/2 Andrew Dunstan : On Cygwin version 1.7.5 I am trying to run set up a member of the PostgreSQL Buildfarm http://www.pgbuildfarm.org/cgi-bin/show_status.pl. We have a current Cygwin member (run by me) using Cygwin version 1.5.25, which for the most part runs without major problems. The good news is that even on the latest code, both stable and development, PostgreSQL builds and its core regression tests run with 100% success. The bad news is that I get a segfault when trying to run the regression tests for the embedded PLPerl language. The test fails when it tries to load Postgres' plperl.dll. Hi Andrew, This is because cygwin perl is compiled with gcc-4 and -fstack-protector and you are trying with gcc-3 without -fstack-protector. Installing gcc-4 and doing the configure with CC=gcc-4 should do the trick. Can you please give a set of configure settings that will work? I have not been able to find one. cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: PostgreSQL plperl crash on Cygwin 1.7.5
Reini Urban wrote: 2010/5/2 Andrew Dunstan : On Cygwin version 1.7.5 I am trying to run set up a member of the PostgreSQL Buildfarm http://www.pgbuildfarm.org/cgi-bin/show_status.pl. We have a current Cygwin member (run by me) using Cygwin version 1.5.25, which for the most part runs without major problems. The good news is that even on the latest code, both stable and development, PostgreSQL builds and its core regression tests run with 100% success. The bad news is that I get a segfault when trying to run the regression tests for the embedded PLPerl language. The test fails when it tries to load Postgres' plperl.dll. Hi Andrew, This is because cygwin perl is compiled with gcc-4 and -fstack-protector and you are trying with gcc-3 without -fstack-protector. Installing gcc-4 and doing the configure with CC=gcc-4 should do the trick. Oh, cool, thanks Reini. I'm testing this now. If standard packages like perl are compiled with gcc-4, shouldn't it be the default? cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: PostgreSQL plperl crash on Cygwin 1.7.5
Reini Urban wrote: 2010/5/2 Andrew Dunstan : On Cygwin version 1.7.5 I am trying to run set up a member of the PostgreSQL Buildfarm http://www.pgbuildfarm.org/cgi-bin/show_status.pl. We have a current Cygwin member (run by me) using Cygwin version 1.5.25, which for the most part runs without major problems. The good news is that even on the latest code, both stable and development, PostgreSQL builds and its core regression tests run with 100% success. The bad news is that I get a segfault when trying to run the regression tests for the embedded PLPerl language. The test fails when it tries to load Postgres' plperl.dll. Hi Andrew, This is because cygwin perl is compiled with gcc-4 and -fstack-protector and you are trying with gcc-3 without -fstack-protector. Installing gcc-4 and doing the configure with CC=gcc-4 should do the trick. Sadly, this doesn't fix it. And if I add CFLAGS=-fstack-protector to the build it doesn't even finish linking let alone run. I get errors like: /home/Andrew/bf/root/HEAD/pgsql.1428/src/interfaces/libpq/fe-auth.c:967: undefined reference to `___stack_chk_guard' cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: apparent scheduler problem
Brian Ford wrote: On Tue, 29 Mar 2005, Andrew Dunstan wrote: Recently after upgrading my installation of Cygwin on XP-Pro, I noticed that PostgreSQL started failing one of its regression tests. [snip] The test is for the stats collector, and essentially it does some work, waits a couple of seconds in a fairly brain dead busy/wait loop, and then checks to see if the stats collector has done the work we expect it to have done. [snip] We are wondering if anything is known to have changed in Cygwin recently that could account for this. Sounds to me like yet another case of http://cygwin.com/ml/cygwin/2005-03/msg00730.html That's remarkably ugly :-) Two of us have confirmed that using the latest snapshot DLL fixes the problem for Postgres. When might the fix make it into a release? cheers andrew -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
apparent scheduler problem
Greetings Cygwin people! I do some work with PostgreSQL, including running the build farm. Recently after upgrading my installation of Cygwin on XP-Pro, I noticed that PostgreSQL started failing one of its regression tests. Another user with a completely fresh Cygwin installation has noticed the same thing. The test is for the stats collector, and essentially it does some work, waits a couple of seconds in a fairly brain dead busy/wait loop, and then checks to see if the stats collector has done the work we expect it to have done. Nothing much has changed in this area of Postgres, certainly not since we know a successful test was done a few weeks ago. Some experimentation has shown that the expected result now appears when we ratchet the sleep right up to around 1 minute. We are wondering if anything is known to have changed in Cygwin recently that could account for this. I regret to tell you I have no exact idea when I previously upgraded my Cygwin installation - certainly some time within the last 6 months. So, this would be something that happened not too long ago. Or as Tom Lane, PostgreSQL uber-hacker, put it: It sounds to me like the problem is that the backend executing the test script is in a tight loop (due to the half-baked implementation of sleep()) and for some reason this prevents the stats processes from running --- for a far longer period than it by rights ought to. Ask about recent changes in process scheduling policy. (I suppose that actually it's Windows doing the scheduling, but what we want to know about is cygwin changes that might have affected Windows scheduling parameters.) Any light you can shine on this would be helpful. We're certainly keen to continue to have Cygwin as a supported platform for PostgreSQL (and we'd also love it if we could do pltcl on Cygwin too, but tcl seems to be currently broken ;-( ) cheers andrew -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
