Dave Korn wrote:
If you can tell me how to proceed from here, I'd be happy to throw
in a bunch of manhours to try and find out what's wrong.
http://cygwin.com/acronyms#PPAST
Obviously, if I were able to produce a simple testcase, I would have.
Duh ;-).
There's nothing _obvious_ about
I wrote:
Cygwin is as complex as a Linux kernel.
Christopher Faylor wrote:
*snort* Your lack of credibility is showing.
Your lifelong devotion to being hateful
instead of constructive is showing?
Jokes aside, I can't respond to the fact that you don't believe
a word I say with anything else
Brian Dessent wrote:
Furthermore, threads in the past have
expressed the fact that 2.05b has been very stable and both Ronald and
others have agreed that any major changes in bash would have to be
done very carefully so as not to cause instability.
Uhm. No it's not..
Bash 2.05b is so
Brian Dessent wrote:
David Dindorp wrote:
Uhm. No it's not..
Bash 2.05b is so unstable under Cygwin that it classifies as a
volatile chemical. At least if you put it under a lot of pressure -
a normal users everyday use it may cope fine with, which is probably
how it's used by most people
Corinna Vinschen wrote:
On Apr 8 12:19, David Dindorp wrote:
To be fair, this is probably more a Cygwin DLL problem than a bash
problem, or perhaps a bash hasn't kept up with changes in Cygwin
because the maintainer haven't had the time problem. It's running
quite stable under 1.5.10
If you can tell me how to proceed from here, I'd be happy to throw in
a bunch of manhours to try and find out what's wrong.
If you are happy to throw a bunch of manhours to try and find out
what's
wrong, then the solution is obvious -- learn cygwin that well.
Manhours. Not entire
If you can tell me how to proceed from here, I'd be happy to throw in
a bunch of manhours to try and find out what's wrong.
http://cygwin.com/acronyms#PPAST
Obviously, if I were able to produce a simple testcase, I would have.
Duh ;-).
--
Unsubscribe info:
Merlin Ran wrote:
Corinna Vinschen wrote:
Doesn't http://www.cygwin.com/ml/cygwin/2003-10/msg00169.html explain
it?
No. I learned why using two pids from the post, but it still doesn't
explain why winpid is always increasing.
It's probably a blessing for shells like 'bash' that it *does
Description:
Bash crashes and leaves a stack dump file.
Wanted:
Help debugging, information, hints.
Application:
bash.exe, pid 2716, thread main
Crash location:
/netrel/src/cygwin-snapshot-20050309-1/winsup/cygwin/pinfo.h:178
Exception:
STATUS_ACCESS_VIOLATION at eip=61056EBC in
Seems harmless, just thought I'd ask.
What does this error mean?
---
agent.sh: line 1:
add_process: pid 592 (rm -f $tmpfile0 /dev/null) is still alive
---
(Snapshot 20050309 installed couple of minutes ago.)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem
Dave Korn wrote:
David Dindorp wrote:
Version:
Cygwin DLL 2005-03-04
Source location:
/netrel/src/cygwin-snapshot-20050304-1/winsup/cygwin/pinfo.h:178
Stack trace:
Exception: STATUS_ACCESS_VIOLATION at eip=[SNIP]
End of stack trace (more stack frames may be present)
I'd be happy
Version:
Cygwin DLL 2005-03-04
bash 2.05b-17
Where:
Bash script. Code:
let fieldno=$counter+1
-x output:
++ let fieldno=0+1
Reproducability:
Happened two times so far.
Above line runs a couple of hundred times without crashing at first.
Doesn't happen in 20050226.
Source
Cristopher Faylor wrote:
David Dindorp wrote:
Bash seems to think that it's child has terminated prematurely.
Has anyone experienced something similar?
Being precise is one thing you could do.
I tried my best.
You could also provide cygcheck output as is
suggested by http://cygwin.com
First step is to go somewhere else.
This is the wrong place for your issues, and you've already been told.
Persisting to post irrelevant questions here will only make people
ignore you and/or hate your guts.
Trust me. It's an evil gang in here, and they will make you suffer.
Support for
sync_with_child:
child 3276(0x118) died before initialization with status code 0x80
30328 [main] bash 4428 sync_with_child:
*** child state waiting for longjmp
agent.sh: fork: Resource temporarily unavailable
David Dindorp wrote:
So far a couple of things have popped up in testing. Only
Trust me. It's an evil gang in here, and they will make you suffer.
Awww, shucks, we're not evil, we're just mean
(http://cygwin.com/acronyms/#WJM). :-)
I dunno. I agree that this is off-topic but claiming that people will
hate your guts seems a little hyperbolic to me.
I stand corrected.
Christopher Faylor wrote (quotes rearranged wildly):
If you are running your own version of bash, then all bets are off.
Just double-checked. BASH_VERSION='2.05b.0(1)-release'.
I thought I was running 3.00 on Cygwin (I am on all other platforms),
but apparently I was just making an ass of
Dave Korn wrote:
David Dindorp wrote:
Just double-checked. BASH_VERSION='2.05b.0(1)-release'.
I thought I was running 3.00 on Cygwin (I am on all other platforms),
but apparently I was just making an ass of myself on a public mailing
list (again?)
Welcome to our world!
Version number
In the meanwhile, does anybody have any comments to offer regarding
this? (Besides stop asking, that is...)
Bash hangs. Both occurrences have been at the same specific script
line, and both produce similar gdb output.
Script line:
lffields[$counter]=`echo $lfline|cut -d'|' -f$fieldno`
Bash seems to think that it's child has terminated prematurely.
Has anyone experienced something similar?
Evidence: See the order of execution in the script below,
compare with what bash does (further below).
Version: snapshot 20050226 / bash 3.0.
If I'm grossly missing anything from my error
Dave Korn wrote:
Hmm. You appear to have told tar to create the output archive
in the root directory of the filing system.
Hm, actually $arcrfname contains a full path, including /cygdrive/c/...
I cut it from the script and output because it made it entirely
unreadable (partly related to my
Cristopher Faylor wrote:
David Dindorp wrote:
Bash seems to think that it's child has terminated prematurely.
Has anyone experienced something similar?
Evidence: See the order of execution in the script below,
compare with what bash does (further below).
Version: snapshot 20050226 / bash 3.0
Mike Dillinger wrote:
I was wondering if there is a command-line mail client for Cygwin?
There's smtppush.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
Christopher Faylor wrote:
If that was really true, you'd be using a snapshot by now.
Ok, ok, I can take a hint (sort of).
I'll give up trying to drill down bugs in 1.5.10.
Has the problem been found that results in this error?:
MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6
At
Christopher Faylor wrote:
Ah, yes! You're the you don't want people to debug cygwin because
you
aren't spoon feeding me debugging information guy!
That is nowhere near what was said.
I said you should provide debugging versions of Cygwin, since large
software packages are hell to build. I
Christopher Faylor wrote:
Actually, we do. We provide the source code. It's easy to build.
You are right; I was wrong. Building Cygwin is easy.
(At least when it comes to newer versions :-p.)
It even compiles under itself. *impressed*.
It's been a few weeks, and I've tested with the debug
Igor Pechtchanski wrote:
Umm, that was my bad. The thing is, --enable-debugging really
produces
a developer debug version, with extra tracing, etc. If all you want
is a
version of DLL with all the symbols (i.e., unstripped), the regular
build
produces that as well.
Cristopher Faylor wrote:
Ack!
Apologies for the formatting.
The company I'm employed at uses Outlook (thereby MS-WORD) for e-mail.
Here's what I wanted to say:
The FAQ entry 105 links to entry 102 under how to compile.
Shouldn't this point to 104 instead?
--
Unsubscribe info:
Cristopher Faylor wrote:
Again, this doesn't address your immediate concern.
A snapshot is your best bet.
Using the snapshot in the test environment, I now get these errors:
sleep.exe (1924): *** MapViewOfFileEx(0x188, in_h 0x188) failed,
Win32
error 6
Any ideas why this occurs?
Can you
Cristopher Faylor wrote:
Actually, we do. We provide the source code. It's easy to build.
On your particular system which is tuned to do precisely this, maybe.
If it's as easy as you say, I'll spend some more time on it.
Have you even tried it?
No. For a couple of reasons.
1. Prior
It's a bit more complicated than that, but thank you for the valuable
input :-).
Gary R. Van Sickle wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Dindorp
Sent: Thursday, January 20, 2005 1:13 PM
To: Cygwin List
Subject: Re: cygwin
Christopher Faylor wrote:
David Dindorp wrote:
The snapshots page says that it's a stripped version.
Who should I trust, the snapshot page or the FAQ?
You should trust me when I tell you that the snapshots
haven't been stripped recently.
You sound authoritative. I'll do that.
There's
Joshua Daniel Franklin wrote:
Well, how about this then:
[snip]
Here's my shot at what would've helped me a lot when I initially faced
problems. Of course providing as much info as below will only leave
you with more newbies crying 'cygwin_split_path() : 0x61073e06' or such.
+ More
Bill Hughes wrote:
I don't think I'm putting this very well, but it may make the FAQ
easier if the standard advice is to load the snaphot and use that for
debugging, it removes a separate layer of potential problems in
building the dll.
And there's still the issue that problems that are
Again, this doesn't address your immediate concern.
A snapshot is your best bet.
Using the snapshot in the test environment, I now get these errors:
rm.exe (2512): *** MapViewOfFileEx(0x1D0, in_h 0x1D0) failed, Win32
error 6
awk.exe (1164): *** MapViewOfFileEx(0x1B0, in_h 0x1B0) failed, Win32
Corinna Vinschen wrote:
IMHO you're looking from the wrong direction. People capable of
debugging the Cygwin DLL are usually also capable of building it.
The only reason that the above is true is because you do not provide
the means for people to debug the Cygwin DLL properly.
I'm wondering
Does no-one have any information on this?
Have I failed to follow the cygwin.com posting guidelines properly?
Too little information?
Help! :-)
Regards
/david
-Original Message-
Hi
I need some information on how to debug Cygwin processes.
We have a partially cygwin-based project,
From what I've seen, it's a very clean install, also easily removable.
It might mess up existing applications which use cygwin though.
To see if you've got any such you could try and scan your harddrive for
cygwin1.dll, or check the registry for the existance of these keys:
Larry Hall wrote:
I have the following suggestions/questions:
1. Did you try a Cygwin 1.5.12 or even a snapshot?
No. I'm using 1.5.10, and it still smells *real* fresh, I think ;-).
Also, the problem only occurs on a customer system which unfortunately
I can't go around and upgrade all the
David Dindorp wrote:
Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was
easy.
Christopher Faylor wrote:
Since cygwin isn't built with debugging symbols, the symbols that you
do
see in gdb are basically meaningless.
Isn't there any way to compile the debugging symbols
Hi
I need some information on how to debug Cygwin processes.
We have a partially cygwin-based project, which are having some
problems.
The cygwin part of the project has some scripts running in a bash
process.
The scripts seem to run fine for a random amount of time.
Sometimes it's mere minutes
41 matches
Mail list logo
