X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Message-ID: <47D71630.8050508@tlinx.org> Date: Tue, 11 Mar 2008 16:30:56 -0700 From: Linda Walsh User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Incident: gdb.exe seems to fail when launched from win (and no cygprogs in stack). References: <47D4A7E4 DOT 5070509 AT tlinx DOT org> <47D4B7D2 DOT 1F78DADB AT dessent DOT net> <47D4E892 DOT 1090305 AT tlinx DOT org> <47D50BB6 DOT EFB28302 AT dessent DOT net> <47D6056B DOT 6000805 AT tlinx DOT org> <47D610C2 DOT EECE7EE9 AT dessent DOT net> In-Reply-To: <47D610C2.EECE7EE9@dessent.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Brian Dessent wrote: > Linda Walsh wrote: >> There...now you've done it. You had me break 'gdb'. > > - The reduced testcase is: int main(int, char **) { fork(); } ----- (well, the int, char** was complained about, but I thought that should have done it...BUT, it not only doesn't give the error, neither does the original problematic binary. The same binary that didn't work yesterday *is* *working* today. I haven't rebooted (but my system did hibernate, so maybe that re-arranged memory?), nor run any updates. Perhaps it was a memory fragmentation issue, though not sure why it was so specific to directory what it was called from. So as I hinted before but now "have to": ignore the running test.exe's- as-called-from-windows "problem". (grrrr....I really hate it when a bug goes away for no reason -- since I don't know what was wrong, I don't know when or if it will come back at some inopportune time). That being said...gdb.exe is still failing with the same error --.... Who knows...if I just ignore it and don't use gdb.exe in 'cmd.exe' (as called direct from win, no underlying cygwin shell), I won't get the error.... At least temporarily, the gdb.exe failure (under specific conditions) isn't highest on my priority list. And if I can't reproduce the other error, then I can't spend time trying to figure that one out... So...until I can figure out what made it go away (or what caused it in the first place), I can't ask anyone else to look at it...). Meanwhile, your idea of "gvim->"gvim&" (maybe a shell function so it can take parameters) and skipping fork altogether, just making it a non-backgrounding redirect for sake of launching gvim from correct path seems the best way to proceed. Thanks for helping me hash out some ways to move forward (even though the underlying technical junk is still 'weird').... I just hate times like these -- either everything is blowing up around me for no good reason, or things just "go away" and nothing's happing and I try to remember what I was doing before all the problems arose (like the being up to ass in alligators when objective was to drain swamp).... *sigh* Thanks again Brian for the hashing...it's given me some good ideas to circumvent the problem -- so maybe I won't get bitten by it in the future should circumstances even arise that it "might have"... Linda -- 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/