uot;oh no!".
Output on Cygwin:
$ jq -n 'error("oh no!")'
assertion "cb == jq_util_input_next_input_cb" failed: file
"/cygdrive/d/a/scallywag/jq/jq-1.7.1-1.x86_64/src/jq-1.7.1/src/util.c", line
360, function: jq_util_input_get_position
Weitergeleitete Nachricht
Von:
An:
Datum: Mo, 28 Nov 2022 13:25:52 +0100
Betreff: Fish crash (topic_monitor.cpp:58: failed assertion: unexpected failure)
Weitergeleitete Nachricht
Your message has been rejected, probably because you are not
Am 20.11.2020 um 03:04 schrieb Duncan Roe:
On Fri, Nov 20, 2020 at 09:19:29AM +0900, cygwin wrote:
Hi all,
On Fri, 20 Nov 2020 11:06:58 +1100
Duncan Roe wrote:
On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote:
It does not seem to happen in xterm which is weird.
It happens in an x
On Fri, Nov 20, 2020 at 09:19:29AM +0900, cygwin wrote:
> Hi all,
>
> On Fri, 20 Nov 2020 11:06:58 +1100
> Duncan Roe wrote:
> > On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote:
> > >
> > > It does not seem to happen in xterm which is weird.
> >
> > It happens in an xterm for me.
> > x
On Fri, Nov 20, 2020 at 09:19:29AM +0900, cygwin wrote:
> Hi all,
>
> On Fri, 20 Nov 2020 11:06:58 +1100
> Duncan Roe wrote:
> > On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote:
> > >
> > > It does not seem to happen in xterm which is weird.
> >
> > It happens in an xterm for me.
> > x
Hi all,
On Fri, 20 Nov 2020 11:06:58 +1100
Duncan Roe wrote:
> On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote:
> >
> > It does not seem to happen in xterm which is weird.
>
> It happens in an xterm for me.
> xterm is /dev/pty1 and mintty is /dev/pty0. They both do it.
> So I think i
On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote:
>
> It does not seem to happen in xterm which is weird.
It happens in an xterm for me.
xterm is /dev/pty1 and mintty is /dev/pty0. They both do it.
So I think it has to be pseudo-console.
(xterm has DISPLAY set to a Linux system but tha
De : Cygwin de la part de Thomas Wolff
Envoyé : 19 novembre 2020 13:30
À : cygwin@cygwin.com
Objet : Re: Failed assertion dialog box ATTN: Takashi Yano
---
Am 19.11.2020 um 15:21 schrieb André Bleau via
.txt 2>&1
Aborted (core dumped)
No message box popup.
$ cat output.txt
assertion "false" failed: file "assert.cpp", line 3, function: int main()
In the original mintty window, with empty CYGWIN env variable:
$ ./a.exe output.txt 2>&1
Aborted (core dumped)
---
De : Cygwin de la part de André Bleau via Cygwin
Envoyé : 15 novembre 2020 15:39
À : The Cygwin Mailing List
Objet : Re: Failed assertion dialog box
info:
>
> It seems the bug is related to pseudo-console support; that explains why
> it is Windows 10 specific.
>
> Experiment:
>
> CYGWIN=disable_pcon /usr/bin/mintty &
>
> In the newly created window:
>
> $ ./a.exe output.txt 2>&1
> Aborted (core dumped
---
De : Cygwin de la part de André Bleau via Cygwin
Envoyé : 15 novembre 2020 15:04
À : The Cygwin Mailing List
Objet : Re: Failed assertion dialog box
---
De : Cygwin de la part de William M. (Mike) Miller
via Cygwin
Envoyé : 15 novembre 2020 08:12
À : The Cygwin Mailing List
Objet : Re: Failed assertion dialog box
On Sat, Nov 14, 2020 at 11:49 PM Duncan
0, cygwin wrote:
> > > > I've run into a problem running a collection of tests under Cygwin
> and I
> > > > wonder if anyone can suggest a way around it.
> > > >
> > > > The problem occurs when a program being run fails a C/C++ runtime
> > >
under Cygwin and I
> > > wonder if anyone can suggest a way around it.
> > >
> > > The problem occurs when a program being run fails a C/C++ runtime
> > > assertion. Ordinarily, this just writes an error message on stderr and
> > > aborts. Under Cygwin, how
3, 2020 at 12:27:57PM -0500, cygwin wrote:
> > > > > > I've run into a problem running a collection of tests under
> Cygwin
> > > and I
> > > > > > wonder if anyone can suggest a way around it.
> > > > > >
> > > > >
> > > > > wonder if anyone can suggest a way around it.
> > > > >
> > > > > The problem occurs when a program being run fails a C/C++ runtime
> > > > > assertion. Ordinarily, this just writes an error message on stderr
> >
; > > On Fri, Nov 13, 2020 at 12:27:57PM -0500, cygwin wrote:
> > > > I've run into a problem running a collection of tests under Cygwin
> and I
> > > > wonder if anyone can suggest a way around it.
> > > >
> > > > The problem occur
of tests under Cygwin and I
> > > wonder if anyone can suggest a way around it.
> > >
> > > The problem occurs when a program being run fails a C/C++ runtime
> > > assertion. Ordinarily, this just writes an error message on stderr and
> > > aborts. U
> The problem occurs when a program being run fails a C/C++ runtime
> > assertion. Ordinarily, this just writes an error message on stderr and
> > aborts. Under Cygwin, however, if both stdin and stderr are redirected to
> > files, the program instead pops up a dialog box that
> The problem occurs when a program being run fails a C/C++ runtime
> > assertion. Ordinarily, this just writes an error message on stderr and
> > aborts. Under Cygwin, however, if both stdin and stderr are redirected to
> > files, the program instead pops up a dialog box that
Hi William,
On Fri, Nov 13, 2020 at 12:27:57PM -0500, cygwin wrote:
> I've run into a problem running a collection of tests under Cygwin and I
> wonder if anyone can suggest a way around it.
>
> The problem occurs when a program being run fails a C/C++ runtime
> assertion. O
I've run into a problem running a collection of tests under Cygwin and I
wonder if anyone can suggest a way around it.
The problem occurs when a program being run fails a C/C++ runtime
assertion. Ordinarily, this just writes an error message on stderr and
aborts. Under Cygwin, however, if
/6/2020 3:47 PM, Ken Brown via Cygwin wrote:
> >>>> On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
> >>>>> This command triggers an assertion failure
> >>>>>"ag" is from the_silver_searcher
> >>>>>
> >>>>
On 9/8/2020 3:26 PM, Ken Brown via Cygwin wrote:
On 9/7/2020 4:35 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 4:28 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 3:47 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
This command triggers an assertion failure
On 9/7/2020 4:35 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 4:28 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 3:47 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
This command triggers an assertion failure
"ag" is from the_silver_searcher
$ ag
On 9/6/2020 4:28 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 3:47 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
This command triggers an assertion failure
"ag" is from the_silver_searcher
$ ag 2 <(echo 2)
assertion "p >= path" f
On 9/6/2020 6:15 PM, David Dyck wrote:
On Sun, Sep 6, 2020 at 12:07 PM Eliot Moss mailto:m...@cs.umass.edu>> wrote:
>
> On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
> > This command triggers an assertion failure
> > "ag" is from the_silver_
On Sun, Sep 6, 2020 at 12:07 PM Eliot Moss wrote:
>
> On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
> > This command triggers an assertion failure
> >"ag" is from the_silver_searcher
> >
> > $ ag 2 <(echo 2)
> > assertion "p >= path
On 9/6/2020 3:47 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
This command triggers an assertion failure
"ag" is from the_silver_searcher
$ ag 2 <(echo 2)
assertion "p >= path" failed: file
"/home/corinna/src/cygwin/cygwin-
On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
This command triggers an assertion failure
"ag" is from the_silver_searcher
$ ag 2 <(echo 2)
assertion "p >= path" failed: file
"/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/wi
On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
This command triggers an assertion failure
"ag" is from the_silver_searcher
$ ag 2 <(echo 2)
assertion "p >= path" failed: file
"/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/wi
Hi Ken,
On 11/12/2019 16:03, Ken Brown wrote:
On 11/4/2019 7:49 AM, Tim Adye wrote:
Hi Ken,
On 31/10/2019 18:19, Ken Brown wrote:
[Please don't top-post on this list. Thanks.]
On 10/30/2019 7:56 PM, Tim Adye wrote:
I'm afraid I get a very similar error with 3.1.0-0.7:
as
On 11/4/2019 7:49 AM, Tim Adye wrote:
> Hi Ken,
>
> On 31/10/2019 18:19, Ken Brown wrote:
>> [Please don't top-post on this list. Thanks.]
>>
>> On 10/30/2019 7:56 PM, Tim Adye wrote:
>>> I'm afraid I get a very similar error with 3.1.0-0.7:
>>
Hi Ken,
On 31/10/2019 18:19, Ken Brown wrote:
[Please don't top-post on this list. Thanks.]
On 10/30/2019 7:56 PM, Tim Adye wrote:
I'm afraid I get a very similar error with 3.1.0-0.7:
assertion "p >= path" failed: file
"/home/kbrown/src/cygpackages/cygwin/cygwin
[Please don't top-post on this list. Thanks.]
On 10/30/2019 7:56 PM, Tim Adye wrote:
> I'm afraid I get a very similar error with 3.1.0-0.7:
>
> assertion "p >= path" failed: file
> "/home/kbrown/src/cygpackages/cygwin/cygwin-3.1.0-0.7.x86_64
Hi Ken,
I'm afraid I get a very similar error with 3.1.0-0.7:
assertion "p >= path" failed: file
"/home/kbrown/src/cygpackages/cygwin/cygwin-3.1.0-0.7.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc",
line 2906, function: int symlink_info::check(char*,
Hi Ken,
Thanks for the promising idea. I could reproduce the assertion with the
examples like '\\?\DRIVE' given in the other thread, so I have now
upgraded to cygwin-3.1.0-0.7. This fixes the '\\?\DRIVE' assertion.
Since my case only happens from time to time, I'll ha
er signature. From time to time my PC gets into a state where no Cygwin
> command will start. They all exit with the message:
>
> C:\>C:\cygwin\bin\bash.exe
> assertion "p >= path" failed: file
> "/home/corinna/src/cygwin/cygwin-3.0.7/cygwin-3.0.7-1.x86_64/src/n
mmand will start. They all exit with the message:
C:\>C:\cygwin\bin\bash.exe
assertion "p >= path" failed: file
"/home/corinna/src/cygwin/cygwin-3.0.7/cygwin-3.0.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc",
line 2916, function: int symlink_info::check(char
> From: Jon Turney [mailto:jon.tur...@dronecode.org.uk]
> Sent: Monday, October 19, 2015 7:54
>
> The dependency chain is git-gui -> gitk -> font-adobe-dpi75
>
> It doesn't look like the fonts in xorg-x11-fonts-Type1 are available to
> fontconfig, so I've changed the dependency of gitk to dejavu-
On 16/10/2015 19:29, Yaakov Selkowitz wrote:
On Fri, 2015-10-16 at 17:09 +, Matt Seitz (matseitz) wrote:
A few days ago, I ran Setup to update my currently installed package, including
my git packages. Since then, whenever I run git gui, I get the following error:
$ git gui
assertion
On Fri, 2015-10-16 at 17:09 +, Matt Seitz (matseitz) wrote:
> A few days ago, I ran Setup to update my currently installed package,
> including my git packages. Since then, whenever I run git gui, I get the
> following error:
>
> $ git gui
> assertion "font != NULL
A few days ago, I ran Setup to update my currently installed package, including
my git packages. Since then, whenever I run git gui, I get the following error:
$ git gui
assertion "font != NULL" failed: file
"/usr/src/ports/fontconfig/fontconfig-2.11.1-3.x86_64/src/fontco
On 6/21/2013 4:21 AM, Corinna Vinschen wrote:
On Jun 21 03:26, Charles Wilson wrote:
The following statement:
char * tmp_path =
(char *) cygwin_create_path (CCP_POSIX_TO_WIN_A, newargz[0]);
Results in this error popup (and a coredump), when newargz[0] is
NULL. Sure, it's a bug in my progra
On Jun 21 03:26, Charles Wilson wrote:
> The following statement:
>
> char * tmp_path =
>(char *) cygwin_create_path (CCP_POSIX_TO_WIN_A, newargz[0]);
>
> Results in this error popup (and a coredump), when newargz[0] is
> NULL. Sure, it's a bug in my program to do that...but shouldn't it
> be
urn a NULL, rather than SIGABRT?
Failed assertion
src
at line 675 of file
/home/corinna/src/cygwin/cygwin-1.7.21/64/cygwin-1.7.21-5/src
/src/winsup/cygwin/path.cc
in function void path_conv::check(const char*, unsigned int, const
suffix_info*)
--
Chuck
--
Problem reports: http://
o not encounter the assert.
Z:\>iozone -a
assertion "root_idx != -1" failed: file "/ext/build/netrel/src/cygwin-1.7.1-1/wi
nsup/cygwin/mount.cc", line 363, function: void mount_info::init()
It means you are using an old version of cygwin. If you upgrade (the
current ver
ozone -a
assertion "root_idx != -1" failed: file "/ext/build/netrel/src/cygwin-1.7.1-1/wi
nsup/cygwin/mount.cc", line 363, function: void mount_info::init()
Stack trace:
Frame Function Args
002299C0 7C802542 (07D8, EA60, 00A4, 00229AB4)
00229AD0 610BADB3 (
On Sun, Feb 28, 2010 at 03:00:54PM -0500, Christopher Faylor wrote:
>On Sun, Feb 28, 2010 at 02:40:37PM -0500, Bill Meier wrote:
>> From time to time I've been
>>getting 'assertion "root_idx != -1" failed ...' cygwin crashes.
>
>I've found that
On Sun, Feb 28, 2010 at 02:40:37PM -0500, Bill Meier wrote:
> From time to time I've been
>getting 'assertion "root_idx != -1" failed ...' cygwin crashes.
I've found that this is usually a race that happens when you start two
Cygwin programs at the same tim
From time to time I've been
getting 'assertion "root_idx != -1" failed ...' cygwin crashes.
(I think the crashes started after I upgraded cygwin to 1.7...).
I finally decided to see if I could reliably reproduce the crash.
I've found that if I run a command
dbin_cxc_4/bin/cpfls.exe
> assertion "ent->fts_info == FTS_NSOK || state.type != 0" failed: file
> "/usr/src/findutils-4.5.4-1/src/findutils-4.5.4/fi
> nd/ftsfind.c", line 475, function: consider_visiting
> Aborted (core dumped)
>
> Is this a known problem?
I am running version 1.7 of Cygwin on my Windows 2003 box. It runs
really well except for a problem that I see quite often.
When executing find I get the following error:
$ find . -name cpfls.exe
./cpfcmdbin_cxc_4/debug/cpfls.exe
./cpfcmdbin_cxc_4/bin/cpfls.exe
assertion "ent->
On Sun, Jul 5, 2009 at 6:58 PM, Dave Korn wrote:
> It's not a full core dump, it's just a stack backtrace in human-readable
> format. If you copy and paste the addresses in the second column (Function)
> into "addr2line --exe " (and assuming you compiled
> with debug info), it'll turn them into a
Roman Werpachowski wrote:
> On Sun, Jul 5, 2009 at 1:50 PM, Dave Korn wrote:
>> Well, what happened was that there's a bug somewhere, and while cygwin was
>> in the process of dumping the stack trace for the abort caused by your
>> assertion firing,
>
> One m
On Sun, Jul 05, 2009 at 05:21:50PM +0100, Roman Werpachowski wrote:
>On Sun, Jul 5, 2009 at 1:50 PM, Dave Korn wrote:
>> ?Well, what happened was that there's a bug somewhere, and while cygwin was
>> in the process of dumping the stack trace for the abort caused by your
>>
On Sun, Jul 5, 2009 at 1:50 PM, Dave Korn wrote:
> Well, what happened was that there's a bug somewhere, and while cygwin was
> in the process of dumping the stack trace for the abort caused by your
> assertion firing,
One more question: how can I use this stack trace to debug
On Sun, Jul 5, 2009 at 3:28 PM, Dave Korn wrote:
> Right, well that shows you're using 1.5.25, which is known to have bugs in
> this area, and is at end-of-life and won't be fixed. It's a minor
> inconvenience, sorry, but it only affects things that happen after your
> program crashes anyway, so
On Sun, Jul 5, 2009 at 3:28 PM, Dave Korn wrote:
> Roman Werpachowski wrote:
>> On Sun, Jul 5, 2009 at 1:50 PM, Dave
>
> Please don't quote the "From:" address in your email.
Extremely sorry, won't happen again. BTW, couldn't the mailing
software automatically remove these addresses?
> Tried 1
Roman Werpachowski wrote:
> On Sun, Jul 5, 2009 at 1:50 PM, Dave
> Korn wrote:
Please don't quote the "From:" address in your email. Getting someone
spammed is no way to thank them for helping you! (See
http://cygwin.com/acronyms/#PCYMTNQREAIYR for a full explanation.)
>> Actually even more
end the
> cygcheck.out file ** as an attachment, not inline, please ** to the list with
> your post.
Done.
> Well, what happened was that there's a bug somewhere, and while cygwin was
> in the process of dumping the stack trace for the abort caused by your
> assertion firing, th
bout segmentation fault? It confuses the hell out of me.
Well, what happened was that there's a bug somewhere, and while cygwin was
in the process of dumping the stack trace for the abort caused by your
assertion firing, the DLL itself had a segfault, and had to give up. It said
"prob
Some more details about my problem
(http://cygwin.com/ml/cygwin/2009-07/msg00150.html)
$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure -
-verbose --program-suffix=-3 --prefix=/usr --exec-prefix=/usr
On Sun, Jul 05, 2009 at 04:18:44AM +0100, Roman Werpachowski wrote:
>I get the following output:
>
> 4 [sig] a 1408 _cygtls::handle_exceptions: Error while dumping
>state (probably corrupted stack)
>Segmentation fault (core dumped)
>
>When running the following test programs:
>
>#include
>
>i
I get the following output:
4 [sig] a 1408 _cygtls::handle_exceptions: Error while dumping
state (probably corrupted stack)
Segmentation fault (core dumped)
When running the following test programs:
#include
int main(void)
{
assert( 1 == 0 );
return 0;
}
or
#include
#include
"Phil Betts" writes:
> Corinna Vinschen wrote:
>> On Jun 19 17:55, Haojun Bao wrote:
>> > hi,
>> >
>> > Here's a test case to make find(1) assertion:
>> >
>> > mkdir no-such-dir/foo/bar: -p
>> >
>> >
Phil Betts wrote:
mkdir -p foo/c:
cd foo
rm -rf c:/
In case you can't see why that's bad, DON'T TRY IT!! Don't even copy
it, because you will accidentally paste it into a terminal window, you
will get to say "oopsy!" [1], and you will hurt your forehead on
your keyboard.
[OT]
I have a wo
Corinna Vinschen wrote:
> On Jun 19 17:55, Haojun Bao wrote:
> > hi,
> >
> > Here's a test case to make find(1) assertion:
> >
> > mkdir no-such-dir/foo/bar: -p
> >
> > #this will not assert
> > find no-such-dir/
> >
>
On Jun 19 17:55, Haojun Bao wrote:
> hi,
>
> Here's a test case to make find(1) assertion:
>
> mkdir no-such-dir/foo/bar: -p
>
> #this will not assert
> find no-such-dir/
>
> mkdir no-such-dir/foo/c: -p
I think the right answer her
hi,
Here's a test case to make find(1) assertion:
mkdir no-such-dir/foo/bar: -p
#this will not assert
find no-such-dir/
mkdir no-such-dir/foo/c: -p
#this will assert now
find no-such-dir/
#this wil not assert
cd no-such-dir/foo/; find .; cd -
../arm-wince-mingw32ce
> /lib/dllcrt3.o:/cygdrive/e/pedro/cegcc/0.50/src/mingw/dllcrt1.c:60: first
> defined here
> /opt/mingw32ce/lib/gcc/arm-wince-mingw32ce/4.1.0/../../../../arm-wince-mingw32ce
> /bin/ld: BFD 2.17.50 20061004 assertion fail
> /cygdrive/e/pedro/cegcc/0.50/src/binu
/../../arm-wince-mingw32ce
/bin/ld: BFD 2.17.50 20061004 assertion fail
/cygdrive/e/pedro/cegcc/0.50/src/bi
nutils/bfd/coff-arm.c:2040
make: *** [libavcodec/libavcodec.so.51] Error 1
What iam doing wrong? Is this a bug in ffmpeg, cygwin, cegcc or ld???
Greatz
mccoffein
--
Unsubscribe info:
u only have 6.9-3; you may want to consider upgrading.
>
> > I have a
> >
> > tail -n 1000 -F -s 0.1 ~/putty.log
> >
> > running all the time since many weeks. Tonight it crashed with the message:
> >
> > assertion "0 <= seconds" failed: file
> &
e version 2.510.2.2, but
cygwin itself is at version 1.5.24. Also, coreutils is now at 6.9-4,
while you only have 6.9-3; you may want to consider upgrading.
> I have a
>
> tail -n 1000 -F -s 0.1 ~/putty.log
>
> running all the time since many weeks. Tonight it crashed w
[EMAIL PROTECTED] wrote:
> .globl ___gmpn_divexact_1
> ___gmpn_divexact_1:
> addl$_GLOBAL_OFFSET_TABLE_, %edx
> movl[EMAIL PROTECTED](%edx), %edx
Win32 does not use PLT/GOT, so this code cannot work.
> This code snippet comes directly from the new GMP 4.2 (GNU Mu
There's a serious bug in the latest version (2.16.91 20050610) of the
GNU assembler (as) for Cygwin. A small snippet of code triggers an
assertion failure. (This code appears in the new GMP 4.2, so it
prevents Cygwin from building GMP.)
STEPS TO REPRODUCE:
(1) Copy the six lines of 486 ass
Hello,
I'm using the negative lookahead assertion in a regular expression to
parse tokens of a text file that start with a '>'. Some of the tokens can
be very long like 500, 1000 or up to 2000 lines long. It seems that the
negative lookahead assertion fails on tokens that are t
.. done. ==> CWD
/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/3/i386/iso ... done.
==> PORT ... done.==> RETR FC3-i386-DVD.iso ... done.
[<=> ] -1,828,556,800 517.56K/s
assertion "bytes >= 0" failed: file
"/home/hack/pro
On Fri, Sep 19, 2003 at 02:34:37PM -0400, Rolf Campbell wrote:
>Christopher Faylor wrote:
>>This problem sounded familiar so I did a little archive diving. It was
>>reported before and I investigated it before. I remember thinking that
>>this would be hard to fix owing to a race condition with si
Christopher Faylor wrote:
On Fri, Aug 15, 2003 at 09:10:12PM -0400, Rolf Campbell wrote:
Christopher Faylor wrote:
On Mon, Sep 08, 2003 at 04:44:58PM -0400, Rolf Campbell wrote:
I started a large build, then hit ^Z. Then "fg", and this is what
happened:
A large build shouldn't even recognize
On Fri, Aug 15, 2003 at 09:10:12PM -0400, Rolf Campbell wrote:
>Christopher Faylor wrote:
>>On Mon, Sep 08, 2003 at 04:44:58PM -0400, Rolf Campbell wrote:
>>>I started a large build, then hit ^Z. Then "fg", and this is what
>>>happened:
>>A large build shouldn't even recognize the ^Z if you are r
Christopher Faylor wrote:
On Mon, Sep 08, 2003 at 04:44:58PM -0400, Rolf Campbell wrote:
I started a large build, then hit ^Z. Then "fg", and this is what happened:
A large build shouldn't even recognize the ^Z if you are running this from
the console. Your TERM=xterm below. Are you running this
On Mon, Sep 08, 2003 at 04:44:58PM -0400, Rolf Campbell wrote:
>I started a large build, then hit ^Z. Then "fg", and this is what happened:
A large build shouldn't even recognize the ^Z if you are running this from
the console. Your TERM=xterm below. Are you running this under X?
cgf
--
Unsub
-C pload/SCC target
/c/base2/node> fg
nice -20 make -rsw -C pload/SCC target
assertion "hsig_inited" failed: file
"/netrel/src/cygwin-snapshot-20030908-1/winsup/cygwin/sigproc.cc", line 204
Signal 6
make[1]: *** [__build__equipConf] Interrupt
make: *** [bsp-CC8260] Interr
"Brian Dessent" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Alex Vinokur wrote:
>
> > > The program prints:
> > === Error : 22 Invalid argument ===
> >
> > Which argument?
>
> The flags argument requires at least one of MAP_SHARED or MAP_PRIVATE, I
> think.
>
> Brian
>
It works
Alex Vinokur wrote:
> > The program prints:
> === Error : 22 Invalid argument ===
>
> Which argument?
The flags argument requires at least one of MAP_SHARED or MAP_PRIVATE, I
think.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.co
Alex Vinokur wrote:
> char* ptr = (char*)mmap(0, sz, PROT_READ, 0, fd, 0);
>
>errno = 0;
> if (ptr != MAP_FAILED)
> {
> string str(ptr, ptr+sz);
> munmap(ptr, sz);
> }
> else
> {
> assert (ptr == MAP_FAILED);
> printf ("=== Error : %u %s ===\n", errno, strerror (errn
sert some predicate
> > to be true. If the predicate is indeed true, the program continues
> > normally. If the predicate is false, the program fails.
> > The predicate in this case is "ptr != MAP_FAILED". Thus, the predicate
> > was false when the assertion faile
predicate is false, the program fails.
> The predicate in this case is "ptr != MAP_FAILED". Thus, the predicate
> was false when the assertion failed, and ptr == MAP_FAILED.
>
> To the OP: this means that mmap() did fail for some reason. It should
> have set errno to indicate
> > > > --
> > > > void read_file (char* filename_i)
> > > > {
> > > > int fd = open(filename_i, O_RDONLY);
> > > > assert (fd > 2);
> > > >
> > > > off_t sz = lseek(fd, 0, S
t; > > {
> > > int fd = open(filename_i, O_RDONLY);
> > > assert (fd > 2);
> > >
> > > off_t sz = lseek(fd, 0, SEEK_END);
> > > char* ptr = (char*)mmap(0, sz, PROT_READ, 0, fd, 0);
> > >
> > > assert
ek(fd, 0, SEEK_END);
> > char* ptr = (char*)mmap(0, sz, PROT_READ, 0, fd, 0);
> >
> > assert (ptr != MAP_FAILED); // Here assertion failed
> > if (ptr != MAP_FAILED)
> > {
> > string str(ptr, ptr+sz);
> > munmap(ptr, sz);
> > }
> >
Here is some function.
>
> --
> void read_file (char* filename_i)
> {
> int fd = open(filename_i, O_RDONLY);
> assert (fd > 2);
>
> off_t sz = lseek(fd, 0, SEEK_END);
> char* ptr = (char*)mmap(0, sz, PROT_READ, 0, fd, 0);
>
> assert (ptr != MAP_FAILED); // Here asser
, O_RDONLY);
assert (fd > 2);
off_t sz = lseek(fd, 0, SEEK_END);
char* ptr = (char*)mmap(0, sz, PROT_READ, 0, fd, 0);
assert (ptr != MAP_FAILED); // Here assertion failed
if (ptr != MAP_FAILED)
{
string str(ptr, ptr+sz);
munmap(ptr, sz);
}
close
following:
CP1
CP2
CP2.5
CP2.7
Usage: java [-options] class [args...]
(to execute a class)
or java -jar [-options] jarfile [args...]
(to execute a jar file)
where options include:
assertion "!wait_sig_inited" failed: file
"/netrel/src/cygwin-1.3.18-1/winsup
On Fri, Jan 10, 2003 at 03:46:29PM -, Max Bowsher wrote:
>Lapo Luchini wrote:
>> If I press ^C during a "make" or even a simple bash script I usually
>> get lots of (this is fairly 'new', never seen them before):
>>
>> assertion "!wait_sig_
Lapo Luchini wrote:
> If I press ^C during a "make" or even a simple bash script I usually
> get lots of (this is fairly 'new', never seen them before):
>
> assertion "!wait_sig_inited" failed: file
> "/netrel/src/cygwin-1.3.17-1/winsup/cygwin/s
If I press ^C during a "make" or even a simple bash script I usually get
lots of (this is fairly 'new', never seen them before):
assertion "!wait_sig_inited" failed: file
"/netrel/src/cygwin-1.3.17-1/winsup/cygwin/sigproc.cc", line 538
I see also that
> From: Randall R Schulz [mailto:[EMAIL PROTECTED]]
>
> Is there a reason that the three bits used for lock
> management must be the
> least significant three? The XSB interpreter (XSB is a Prolog
> system) uses
> even more bits, but doesn't demand that they be contiguous.
> Depending on
>
1 - 100 of 107 matches
Mail list logo
