Date: Mon, 6 Dec 2004 00:04:20 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 468 ************************************************** Sunday 05 December 2004 Number 468 ************************************************** Subjects for today 1 Re: No sys/sysctl.h in GCC 3.3.5 : John Poltorak 2 Re: fork and !!!DEADLOCK!!! : lsunley at mb.sympatico.ca 3 Re: No sys/sysctl.h in GCC 3.3.5 : John Poltorak 4 Re: fork and !!!DEADLOCK!!! : lsunley at mb.sympatico.ca 5 Re: No sys/sysctl.h in GCC 3.3.5 : lsunley at mb.sympatico.ca 6 Re: No sys/sysctl.h in GCC 3.3.5 : Steven Levine" 7 Re: fork and !!!DEADLOCK!!! : Knut St. Osmundsen" 8 Re: No controlling tty : John Poltorak 9 Re: No sys/sysctl.h in GCC 3.3.5 : John Poltorak 10 Re: fork and !!!DEADLOCK!!! : lsunley at mb.sympatico.ca 11 Re: No controlling tty : Steve Wendt" **= Email 1 ==========================** Date: Sat, 4 Dec 2004 17:17:06 +0000 From: John Poltorak Subject: Re: No sys/sysctl.h in GCC 3.3.5 On Thu, Dec 02, 2004 at 03:11:03PM +0100, Bart van Leeuwen wrote: > Addressed directly to John: > Since you do such a great effort of trying everything out, and the big > motor behind this list, could you organize a list or something where > people can find utils that are beeing worked on, and the people who work on > that ? I've made efforts to get as many developers as possible on this list but wouldn't so presumptious as to speak on their behalf. Having said that certain projects are definitely being actively developed/maintained. They include gcc, Mozilla, Apache, PHP, Python, wxWindows, MySQL, PostgreSQL, Everblue, XFree86/2 and probably others which I've overlooked. Of course with the excellent updates we have had to the GNU build tools in recent years, quite a lot of apps no longer need a maintainer but build on OS/2 straight out of the box. The one major app which I am interested in but have no about its devlopment status is Open Office. If I have overlooked anything then please feel free to jump in and let me know. > that way we prevent double work, and maybe increase effort if people join > forces. I'm not aware of any duplication of effort and whilst it would be good to see people co-operating on projects, without some degree of project management I don't see it being to successful. > With Regards > Bart van Leeuwen -- John **= Email 2 ==========================** Date: Sat, 04 Dec 2004 11:16:56 -0500 From: lsunley at mb.sympatico.ca Subject: Re: fork and !!!DEADLOCK!!! Hi, I'm glad to hear that you have found and fixed it. I was not looking forward to reducing it to a simple test case...... Do you have a date for releasing the fixes? Thanks for all the work. Lorne In <41B17D8B.3000008 at anduin.net>, on 12/04/04 at 10:04 AM, "Knut St. Osmundsen" said: >lsunley at mb.sympatico.ca wrote: >> Does anyone have a clue what this could mean >> >> DEBUG: Starting: StartChildProcess fork >> >> !!!deadlock!!! LIBC Heap Owner died! >> DEBUG: Starting: StartChildProcess fork pid = -1 >> LOG: could not fork startup process: Invalid argument >> >> This happens when postmaster.exe executes a pid = fork() >I fixed this problem a few days back. I thing I already reported that, >but since you didn't pay attention you get the hear all the details >about it now. ;-) >It was caused by DLLs loaded by dlopen not begin loaded into the child >on fork() as one should expect. The result was that a iconv or setlocale >related function crashed when calling into one of the DLLs. This was >caught by the exception handler and the process exitted. >The very odd warning about the heap owner having died is because the >process was a partial copy of the parent at the time and the heap hadn't >been unlocked yet. Some cleanup code invoked by LIBC DLL termination >code found that it wanted to call free(). >Both issues have been fixed. I've added two new API wrappers, >DosLoadModuleEx and DosFreeModuleEx, which will make sure that the >loaded module will be loaded in the child processes too. And in the case >of the termination code, it will is disabled while the fork is in >progress and should not be invoked on failure. >A third problem - which didn't occure because of the crash - was also >corrected. The heap semaphores was owned by the parent, and releasing >them in the child process would've caused the same message as above. >Kind Regards, > knut -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 3 ==========================** Date: Sat, 4 Dec 2004 17:31:41 +0000 From: John Poltorak Subject: Re: No sys/sysctl.h in GCC 3.3.5 On Thu, Dec 02, 2004 at 06:14:04PM +0100, Sebastian Wittmeier wrote: > Hi Bart, hi John, > perhaps you would also like to coordinate with OSFree (that's the > project which is about programming; FreeOS was about talking). > At the moment they are recreating the command line utilities, porting > ping and tracerte from BSD. See > > http://www.osfree.org/index.php?gobaby=status I just took a quick look. Is OSFree being written using OpenWatcom? It looks as the ping and tracerte are going to be ported to make the compile with OpenWatcom whereas I would expect the them to build straight out of the box with gcc... > Sebastian > > -- John **= Email 4 ==========================** Date: Sat, 04 Dec 2004 11:31:56 -0500 From: lsunley at mb.sympatico.ca Subject: Re: fork and !!!DEADLOCK!!! Hi, Does this mean that I will have to modify the dlopen routine that I wrote for postgreSQL to use the new wrapper DLLs? See emdedded comments in code below... --------- dlopen code ---------------- #include "postgres.h" #include char * dlerror(void) { return "error"; } int dlclose(void *handle) { >>>>> S/B DosFreeModuleEx return DosFreeModule((HMODULE) handle) ? 0 : 1; } void * dlsym(void *handle, const char *symbol) { PFN procAddr = NULL; DosQueryProcAddr((HMODULE) handle, 0, symbol, &procAddr); return (void *) procAddr; } void * dlopen(const char *path, int mode) { HMODULE hDll; CHAR errorMsg[256]; >>>> S/B DosLoadModuleEx DosLoadModule(errorMsg, sizeof(errorMsg) - 1, path, &hDll); return (void *) hDll; } ----------------------------------------------- In <41B17D8B.3000008 at anduin.net>, on 12/04/04 at 10:04 AM, "Knut St. Osmundsen" said: >lsunley at mb.sympatico.ca wrote: >> Does anyone have a clue what this could mean >> >> DEBUG: Starting: StartChildProcess fork >> >> !!!deadlock!!! LIBC Heap Owner died! >> DEBUG: Starting: StartChildProcess fork pid = -1 >> LOG: could not fork startup process: Invalid argument >> >> This happens when postmaster.exe executes a pid = fork() >I fixed this problem a few days back. I thing I already reported that, >but since you didn't pay attention you get the hear all the details >about it now. ;-) >It was caused by DLLs loaded by dlopen not begin loaded into the child >on fork() as one should expect. The result was that a iconv or setlocale >related function crashed when calling into one of the DLLs. This was >caught by the exception handler and the process exitted. >The very odd warning about the heap owner having died is because the >process was a partial copy of the parent at the time and the heap hadn't >been unlocked yet. Some cleanup code invoked by LIBC DLL termination >code found that it wanted to call free(). >Both issues have been fixed. I've added two new API wrappers, >DosLoadModuleEx and DosFreeModuleEx, which will make sure that the >loaded module will be loaded in the child processes too. And in the case >of the termination code, it will is disabled while the fork is in >progress and should not be invoked on failure. >A third problem - which didn't occure because of the crash - was also >corrected. The heap semaphores was owned by the parent, and releasing >them in the child process would've caused the same message as above. >Kind Regards, > knut -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 5 ==========================** Date: Sat, 04 Dec 2004 11:45:01 -0500 From: lsunley at mb.sympatico.ca Subject: Re: No sys/sysctl.h in GCC 3.3.5 In <20041204171706.S83 at warpix.org>, on 12/04/04 at 05:17 PM, John Poltorak said: >On Thu, Dec 02, 2004 at 03:11:03PM +0100, Bart van Leeuwen wrote: >> Addressed directly to John: >> Since you do such a great effort of trying everything out, and the big >> motor behind this list, could you organize a list or something where >> people can find utils that are beeing worked on, and the people who work on >> that ? >I've made efforts to get as many developers as possible on this list but >wouldn't so presumptious as to speak on their behalf. Having said that >certain projects are definitely being actively developed/maintained. They > include gcc, Mozilla, Apache, PHP, Python, wxWindows, MySQL, PostgreSQL, >Everblue, XFree86/2 and probably others which I've overlooked. Don't forget unixODBC for OS/2 (and other ODBC drivers :-) <\shameless plug> >Of course with the excellent updates we have had to the GNU build tools >in recent years, quite a lot of apps no longer need a maintainer but >build on OS/2 straight out of the box. >The one major app which I am interested in but have no about its >devlopment status is Open Office. That is one I am interested in. I have been using the OO source code to attempt to track down problems using Staroffice 5.1 with unixODBC. I started to do some work to set up a build environment, but I got distracted by doing a postgreSQL V8 port. >If I have overlooked anything then please feel free to jump in and let me > know. > >> that way we prevent double work, and maybe increase effort if people join >> forces. >I'm not aware of any duplication of effort and whilst it would be good to > see people co-operating on projects, without some degree of project >management I don't see it being to successful. > >> With Regards >> Bart van Leeuwen We could use a Wiki at netlabs to post projects and status.... -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 6 ==========================** Date: Sat, 04 Dec 2004 10:07:02 -0800 From: "Steven Levine" Subject: Re: No sys/sysctl.h in GCC 3.3.5 In <20041204173141.T83 at warpix.org>, on 12/04/04 at 05:31 PM, John Poltorak said: >I just took a quick look. Is OSFree being written using OpenWatcom? That appears to be the plan. It probably made sense when the project was initiatated. gcc was nowhere it current state of development. I can understand choosing OpenWatcom for kernel level components. It has several advantages over gcc. Support for 16-bit code will be required to fully implemenent a clone of the OS/2 kernel. Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.60b #10183 Warp4/FP15/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 7 ==========================** Date: Sat, 04 Dec 2004 22:51:38 +0100 From: "Knut St. Osmundsen" Subject: Re: fork and !!!DEADLOCK!!! Hi, no you don't need to change your stuff. LIBC have it's own dlfcn.h and implementation of the APIs. Just use that one and you can blame me if something goes wrong. (LIBC have had dlopen and friends since day 1.) I'm not sure when I can put out a new build. I hope it will be this weekend, but I just broke the source tree when updating the FreeBSD part of it and am forced to implement some of the multibyte character and wide character stuff now. (I will of course borrow as much as possible from BSD, so it shouldn't that much of an effort, but still, I cannot say how long it'll take me.) Kind Regards, knut lsunley at mb.sympatico.ca wrote: > Hi, > > Does this mean that I will have to modify the dlopen routine that I wrote > for postgreSQL to use the new wrapper DLLs? See emdedded comments in code > below... > > --------- dlopen code ---------------- > #include "postgres.h" > #include > > char * > dlerror(void) > { > return "error"; > } > int > dlclose(void *handle) > { > > >>>>>>S/B DosFreeModuleEx > > > return DosFreeModule((HMODULE) handle) ? 0 : 1; > } > void * > dlsym(void *handle, const char *symbol) > { > PFN procAddr = NULL; > DosQueryProcAddr((HMODULE) handle, 0, symbol, &procAddr); > return (void *) procAddr; > } > void * > dlopen(const char *path, int mode) > { > HMODULE hDll; > CHAR errorMsg[256]; > > >>>>>S/B DosLoadModuleEx > > DosLoadModule(errorMsg, sizeof(errorMsg) - 1, path, &hDll); > return (void *) hDll; > } > > ----------------------------------------------- > > In <41B17D8B.3000008 at anduin.net>, on 12/04/04 > at 10:04 AM, "Knut St. Osmundsen" said: > > >>lsunley at mb.sympatico.ca wrote: >> >>>Does anyone have a clue what this could mean >>> >>>DEBUG: Starting: StartChildProcess fork >>> >>>!!!deadlock!!! LIBC Heap Owner died! >>>DEBUG: Starting: StartChildProcess fork pid = -1 >>>LOG: could not fork startup process: Invalid argument >>> >>>This happens when postmaster.exe executes a pid = fork() > > >>I fixed this problem a few days back. I thing I already reported that, >>but since you didn't pay attention you get the hear all the details >>about it now. ;-) > > >>It was caused by DLLs loaded by dlopen not begin loaded into the child >>on fork() as one should expect. The result was that a iconv or setlocale >>related function crashed when calling into one of the DLLs. This was >>caught by the exception handler and the process exitted. > > >>The very odd warning about the heap owner having died is because the >>process was a partial copy of the parent at the time and the heap hadn't >>been unlocked yet. Some cleanup code invoked by LIBC DLL termination >>code found that it wanted to call free(). > > >>Both issues have been fixed. I've added two new API wrappers, >>DosLoadModuleEx and DosFreeModuleEx, which will make sure that the >>loaded module will be loaded in the child processes too. And in the case >>of the termination code, it will is disabled while the fork is in >>progress and should not be invoked on failure. >>A third problem - which didn't occure because of the crash - was also >>corrected. The heap semaphores was owned by the parent, and releasing >>them in the child process would've caused the same message as above. > > >>Kind Regards, >> knut > > > **= Email 8 ==========================** Date: Sat, 4 Dec 2004 22:06:26 +0000 From: John Poltorak Subject: Re: No controlling tty On Mon, Nov 22, 2004 at 01:54:36PM +0100, Knut St. Osmundsen wrote: > IIRC EMX implements /dev/tty. LIBC doesn't do that yet. I'm not sure > what the requirements for getting that working 100% are, and it's gonna > take some time investigating it. I ran into the concept of controlling > tty while looking at process groups / job control / signals but haven't > had time to delve into all the details yet. > > Any help on the subject would be appreciated, especially if it includes > code. :-) Have you come across any code yet? Presumably a snippet from EMX would be sufficient... > Kind Regards, > knut -- John **= Email 9 ==========================** Date: Sat, 4 Dec 2004 22:11:42 +0000 From: John Poltorak Subject: Re: No sys/sysctl.h in GCC 3.3.5 On Sat, Dec 04, 2004 at 10:07:02AM -0800, Steven Levine wrote: > In <20041204173141.T83 at warpix.org>, on 12/04/04 > at 05:31 PM, John Poltorak said: > > >I just took a quick look. Is OSFree being written using OpenWatcom? > > That appears to be the plan. It probably made sense when the project was > initiatated. gcc was nowhere it current state of development. > > I can understand choosing OpenWatcom for kernel level components. It has > several advantages over gcc. Support for 16-bit code will be required to > fully implemenent a clone of the OS/2 kernel. OS/2 is built with two different compilers so there is no reason why OSFree should be restricted to one. It just seems that gcc would be more appropriate when it comes to adding in BSD based programs. > Steven > > -- > ---------------------------------------------------------------------- > "Steven Levine" MR2/ICE 2.60b #10183 Warp4/FP15/14.100c_W4 > www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) > ---------------------------------------------------------------------- > -- John **= Email 10 ==========================** Date: Sat, 04 Dec 2004 17:15:56 -0500 From: lsunley at mb.sympatico.ca Subject: Re: fork and !!!DEADLOCK!!! Hi, Great, the less work for me the better :-) I did not realize that LIBC had dlopen, I had to hack it for unixODBC and thought I had to do the same for postgreSQL. I'll have to change the build stuff for unixODBC to use the LIBC one. Lorne In <41B2316A.9090907 at anduin.net>, on 12/04/04 at 10:51 PM, "Knut St. Osmundsen" said: >Hi, >no you don't need to change your stuff. LIBC have it's own dlfcn.h and >implementation of the APIs. Just use that one and you can blame me if >something goes wrong. (LIBC have had dlopen and friends since day 1.) >I'm not sure when I can put out a new build. I hope it will be this >weekend, but I just broke the source tree when updating the FreeBSD part >of it and am forced to implement some of the multibyte character and >wide character stuff now. (I will of course borrow as much as possible >from BSD, so it shouldn't that much of an effort, but still, I cannot >say how long it'll take me.) >Kind Regards, > knut >lsunley at mb.sympatico.ca wrote: >> Hi, >> >> Does this mean that I will have to modify the dlopen routine that I wrote >> for postgreSQL to use the new wrapper DLLs? See emdedded comments in code >> below... >> >> --------- dlopen code ---------------- >> #include "postgres.h" >> #include >> >> char * >> dlerror(void) >> { >> return "error"; >> } >> int >> dlclose(void *handle) >> { >> >> >>>>>>>S/B DosFreeModuleEx >> >> >> return DosFreeModule((HMODULE) handle) ? 0 : 1; >> } >> void * >> dlsym(void *handle, const char *symbol) >> { >> PFN procAddr = NULL; >> DosQueryProcAddr((HMODULE) handle, 0, symbol, &procAddr); >> return (void *) procAddr; >> } >> void * >> dlopen(const char *path, int mode) >> { >> HMODULE hDll; >> CHAR errorMsg[256]; >> >> >>>>>>S/B DosLoadModuleEx >> >> DosLoadModule(errorMsg, sizeof(errorMsg) - 1, path, &hDll); >> return (void *) hDll; >> } >> >> ----------------------------------------------- >> >> In <41B17D8B.3000008 at anduin.net>, on 12/04/04 >> at 10:04 AM, "Knut St. Osmundsen" said: >> >> >>>lsunley at mb.sympatico.ca wrote: >>> >>>>Does anyone have a clue what this could mean >>>> >>>>DEBUG: Starting: StartChildProcess fork >>>> >>>>!!!deadlock!!! LIBC Heap Owner died! >>>>DEBUG: Starting: StartChildProcess fork pid = -1 >>>>LOG: could not fork startup process: Invalid argument >>>> >>>>This happens when postmaster.exe executes a pid = fork() >> >> >>>I fixed this problem a few days back. I thing I already reported that, >>>but since you didn't pay attention you get the hear all the details >>>about it now. ;-) >> >> >>>It was caused by DLLs loaded by dlopen not begin loaded into the child >>>on fork() as one should expect. The result was that a iconv or setlocale >>>related function crashed when calling into one of the DLLs. This was >>>caught by the exception handler and the process exitted. >> >> >>>The very odd warning about the heap owner having died is because the >>>process was a partial copy of the parent at the time and the heap hadn't >>>been unlocked yet. Some cleanup code invoked by LIBC DLL termination >>>code found that it wanted to call free(). >> >> >>>Both issues have been fixed. I've added two new API wrappers, >>>DosLoadModuleEx and DosFreeModuleEx, which will make sure that the >>>loaded module will be loaded in the child processes too. And in the case >>>of the termination code, it will is disabled while the fork is in >>>progress and should not be invoked on failure. >>>A third problem - which didn't occure because of the crash - was also >>>corrected. The heap semaphores was owned by the parent, and releasing >>>them in the child process would've caused the same message as above. >> >> >>>Kind Regards, >>> knut >> >> >> -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 11 ==========================** Date: Sat, 04 Dec 2004 20:42:46 -0800 (PST) From: "Steve Wendt" Subject: Re: No controlling tty On Sat, 4 Dec 2004 22:06:26 +0000, John Poltorak wrote: >> IIRC EMX implements /dev/tty. LIBC doesn't do that yet. >> >> Any help on the subject would be appreciated, especially if it includes >> code. :-) > >Have you come across any code yet? >Presumably a snippet from EMX would be sufficient... EMX has a license that is incompatible with Innotek's LIBC, as I recall. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.)