in-3.6.0-0.346.gfe6ddc15a356.
>
> $ uname -r
> 3.6.0-0.346.gfe6ddc15a356.x86_64
>
> $ time ./mqhang
> mq_send...
> mq_send = 0
> mq_receive...
> mq_receive = 8
> mq_receive...
> mq_send...
> mq_receive = 8
> mq_send = 0
>
> real 0m5.002s
> u
eive = 8
mq_send = 0
real 0m5.002s
user 0m0.000s
sys 0m0.000s
$ stress-ng --workload 16 --timeout 60 --verify
stress-ng: info: [4873] setting to a 1 min run per stressor
stress-ng: info: [4873] dispatching hogs: 16 workload
stress-ng: info: [4874] workload: running with 2 threads pe
On Jan 27 20:35, Corinna Vinschen via Cygwin wrote:
> On Jan 27 19:59, Christian Franke via Cygwin wrote:
> > Christian Franke wrote:
> > > Found with 'stress-ng --workload ...':
> > >
> > > If mq_receive is called on an empty queue and mq_send is called later
> > > from a different thread, both f
On Jan 27 19:59, Christian Franke via Cygwin wrote:
> Christian Franke wrote:
> > Found with 'stress-ng --workload ...':
> >
> > If mq_receive is called on an empty queue and mq_send is called later
> > from a different thread, both functions never return and signals
> > (including SIGKILL) are no
Christian Franke wrote:
Found with 'stress-ng --workload ...':
If mq_receive is called on an empty queue and mq_send is called later
from a different thread, both functions never return and signals
(including SIGKILL) are no longer processed.
Testcase (attached):
$ uname -r
3.5.5-1.x86_64
Found with 'stress-ng --workload ...':
If mq_receive is called on an empty queue and mq_send is called later
from a different thread, both functions never return and signals
(including SIGKILL) are no longer processed.
Testcase (attached):
$ uname -r
3.5.5-1.x86_64
$ gcc -o mqhang mqhang.c
Deter using detached attribute in cygwin. for details [1].
You might find static-linking as useful workaround for this issue which
requires build openssl from source code.
Thread 7 "a" hit Breakpoint 9, init_thread_remove_handlers (
handsin=handsin@entry=0x0) at crypto/initthread.c:178
178
Hi,
(Sent to cygwin-developers by mistake).
When debugging a segfault in the Dillo browser[1] with the DNS threaded
resolver and OpenSSL 3.0.13 I managed to isolate a reproducer.
[1]: https://github.com/dillo-browser/dillo/issues/172
It seems to be caused when both the SSL_library_init() is
Dear Jay,
> On the advice of Jon Turney, I ran a "bt f" command after gdb caught the
> exception, and it appears that a Trend Micro dll (TmUmEvt64.dll) is where the
> error occurs:
Since the message with a similar problem I posted is from April 2016, it would
also make sense to report this to T
On 2019-10-25 20:34, Jay P. Elston wrote:
> On October 25, 2019 6:48 AM, Michael Soegtrop wrote:
>> It has been reported in the past that antivirus software from Trend Micro
>> result in STATUS_GUARD_PAGE_VIOLATION in ntdll!RtlAllocateHeap ().
>> See:
>> http://cygwin.1069669.n5.nabble.com/XWin-sta
On October 25, 2019 6:48 AM, Michael Soegtrop wrote:
>It has been reported in the past that antivirus software from Trend Micro
>result in STATUS_GUARD_PAGE_VIOLATION in ntdll!RtlAllocateHeap ().
>See:
>http://cygwin.1069669.n5.nabble.com/XWin-startup-crash-x86-64-Windows-10-td126544.html#a1265
Dear Jon,
It has been reported in the past that antivirus software from Trend Micro
result in STATUS_GUARD_PAGE_VIOLATION in ntdll!RtlAllocateHeap ().
See:
http://cygwin.1069669.n5.nabble.com/XWin-startup-crash-x86-64-Windows-10-td126544.html#a126561
Best regards,
Michael
Intel Deutschland Gm
On 23/10/2019 18:25, Jay P. Elston wrote:
Hi all,
I developed a problem debugging threads on my Cygwin installed on a Window 7 PC
-- gdb throws an unknown target exception when it gets to the pthread_crreate()
call.
This seems to be saying that the exception isn't thrown when not run
Hi all,
I developed a problem debugging threads on my Cygwin installed on a Window 7 PC
-- gdb throws an unknown target exception when it gets to the pthread_crreate()
call.
This problem seems localized to my PC (even after reinstalling Cygwin), and I
am wondering what my next trouble
On Mon, 15 Jul 2019 09:53:27, Corinna Vinschen wrote:
> On Jul 14 15:19, Houder wrote:
> > .. uhm, just a note in the interest of accuracy ...
> >
> > - standard signals (which include USRSIG1 and USRSIG2) are not queued
> >(traditional signal semantics)
> > - only real-time signals should
On Jul 14 15:19, Houder wrote:
> On Fri, 12 Jul 2019 17:33:51, Corinna Vinschen wrote:
>
> > On Jul 6 19:15, Kenton Varda wrote:
>
> > > I found a second problem which may or may not be related:
>
> > > If two threads use pthread_kill() to send each other
On Fri, 12 Jul 2019 17:33:51, Corinna Vinschen wrote:
> On Jul 6 19:15, Kenton Varda wrote:
> > I found a second problem which may or may not be related:
> > If two threads use pthread_kill() to send each other the same signal,
> > such that the signal should be separ
On Jul 6 19:15, Kenton Varda wrote:
> I found a second problem which may or may not be related:
>
> If two threads use pthread_kill() to send each other the same signal,
> such that the signal should be separately pending on both threads at
> the same time, only one of the
On Jul 6 15:46, Kenton Varda wrote:
> Hello Cygwin,
>
> According to the (Linux) man page: "sigpending() returns the set of
> signals that are pending for delivery to the calling thread"
>
> However, on Cygwin, sigpending() seems to return the set of signals
> pending on any thread, as shown in
I found a second problem which may or may not be related:
If two threads use pthread_kill() to send each other the same signal,
such that the signal should be separately pending on both threads at
the same time, only one of the two signals is actually queued. It
seems that pthread_kill() is
Hello Cygwin,
According to the (Linux) man page: "sigpending() returns the set of
signals that are pending for delivery to the calling thread"
However, on Cygwin, sigpending() seems to return the set of signals
pending on any thread, as shown in the attached test program.
Among other things, thi
is now knowingly ignoring the fact
that the archives require hard wrapping.
David is correct the OP needs to stop breaking threads and using list
etiquette.
That same etiquette would dictate that he implement hard wrapping with his
client, so that others dont have to deal with him (custom CSS vi
On 8/16/2017 6:49 PM, Steven Penny wrote:
> On Wed, 16 Aug 2017 14:27:37, David Macek wrote:
>> Please stop breaking the message threads, it's hard to comprehend
>> what's ha=
>> ppening this way. If needed, I can help with configuring your e-mail
>> clien=
On Wed, 16 Aug 2017 14:27:37, David Macek wrote:
Please stop breaking the message threads, it's hard to comprehend what's ha=
ppening this way. If needed, I can help with configuring your e-mail clien=
t.
You really dont need to be giving people advice about their email client. Gl
Please stop breaking the message threads, it's hard to comprehend what's
happening this way. If needed, I can help with configuring your e-mail client.
--
David Macek
smime.p7s
Description: S/MIME Cryptographic Signature
On Wed, Jun 24, 2015 at 10:33 AM, Eli Zaretskii wrote:
> People who can reproduce this problem and can also build their own GDB
> are encouraged to try the patch posted here:
>
> https://sourceware.org/ml/gdb/2015-06/msg00071.html
>
> and report whether it solves the problem on Cygwin. (I alrea
On Wed, Jun 24, 2015 at 10:33 AM, Eli Zaretskii wrote:
> People who can reproduce this problem and can also build their own GDB
> are encouraged to try the patch posted here:
>
> https://sourceware.org/ml/gdb/2015-06/msg00071.html
>
> and report whether it solves the problem on Cygwin. (I alrea
People who can reproduce this problem and can also build their own GDB
are encouraged to try the patch posted here:
https://sourceware.org/ml/gdb/2015-06/msg00071.html
and report whether it solves the problem on Cygwin. (I already
verified that the native MinGW debugging is fixed by that patch
t;>>> Thanks for the reply. My concern, however, isn't that new threads are
>>>> being created; it's that when gdb does this, it sets the state of all
>>>> threads, including my main thread, to "(running)" so that I can't
>>>> s
On 6/20/2015 4:51 PM, William M. (Mike) Miller wrote:
On Sat, Jun 20, 2015 at 4:42 PM, Ken Brown wrote:
On 6/20/2015 4:02 PM, William M. (Mike) Miller wrote:
Thanks for the reply. My concern, however, isn't that new threads are
being created; it's that when gdb does this, it sets
On Sat, Jun 20, 2015 at 4:42 PM, Ken Brown wrote:
> On 6/20/2015 4:02 PM, William M. (Mike) Miller wrote:
>>
>> Thanks for the reply. My concern, however, isn't that new threads are
>> being created; it's that when gdb does this, it sets the state of all
>>
On 6/20/2015 4:02 PM, William M. (Mike) Miller wrote:
Thanks for the reply. My concern, however, isn't that new threads are
being created; it's that when gdb does this, it sets the state of all
threads, including my main thread, to "(running)" so that I can't
single-st
that
>> I can't step, etc. (although the thread isn't actually running).
>> Here's the scenario:
>>
>> 1) I say "gdb xxx.exe", set a breakpoint, and run. When I hit the
>> breakpoint, "info threads" shows me two threads, one for my execut
; Here's the scenario:
>
> 1) I say "gdb xxx.exe", set a breakpoint, and run. When I hit the
> breakpoint, "info threads" shows me two threads, one for my executable
> and one with some _cygtls/cygthread/ntdll frames; both are stopped.
>
> 2) I say "up
call one of these functions, _sometimes_ gdb will start
a new thread and put my current thread into "running" status, so that
I can't step, etc. (although the thread isn't actually running).
Here's the scenario:
1) I say "gdb xxx.exe", set a breakpoint, and run.
On 6/19/2015 11:05 PM, Daniel wrote:
Marco Atzeri wrote:
On 6/19/2015 7:34 AM, Daniel wrote:
William J. Schilp, PhD wrote:
please use
cygcheck /usr/lib/perl5/5.14/i686-cygwin-threads-64int/auto/IO/IO.dll
It will tell you what other dll's is missing
I included the cygcheck output
Marco Atzeri wrote:
On 6/19/2015 7:34 AM, Daniel wrote:
William J. Schilp, PhD wrote:
I have the same problem (I'm on 32bit). The IO module is broken:
$ ldd /usr/lib/perl5/5.14/i686-cygwin-threads-64int/auto/IO/IO.dll
ntdll.dll => /cygdrive/c/WINDOWS/system32/ntdll.dll (0x
On 6/19/2015 7:34 AM, Daniel wrote:
William J. Schilp, PhD wrote:
I have the same problem (I'm on 32bit). The IO module is broken:
$ ldd /usr/lib/perl5/5.14/i686-cygwin-threads-64int/auto/IO/IO.dll
ntdll.dll => /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c90)
kern
William J. Schilp, PhD wrote:
i updated to the latest version of perl on cygwin and i get the
following failure:
Can't load '/usr/lib/perl5/5.14/i686-cygwin-threads-64int/auto/IO/IO.dll'
for module IO: No such process at /usr/lib/perl5/5.14/XSLoader.pm line
71.
at /usr/lib/
On 03/06/2015 19:41, schilpfamily wrote:
well i didn't want to update everything because of the mess the
cygwin/x people have made of the X port. but after updating everything
it now works. of course cygwin/x doesn't
i guess it's time to purchase some kind of X windows emulator as i
don't thi
On Wed, 2015-06-03 at 14:41 -0400, schilpfamily wrote:
> well i didn't want to update everything because of the mess the
> cygwin/x people have made of the X port. but after updating everything
> it now works. of course cygwin/x doesn't
> i guess it's time to purchase some kind of X windows emu
well i didn't want to update everything because of the mess the
cygwin/x people have made of the X port. but after updating everything
it now works. of course cygwin/x doesn't
i guess it's time to purchase some kind of X windows emulator as i
don't think the cygwin/x people care if they break t
William J. Schilp, PhD writes:
> i updated to the latest version of perl on cygwin and i get the
> following failure:
Your Cygwin installation is most certainly not up-to-date, so I think
you tried to mix-and-match instead of updating. If you do that, you
shouldn't hide the OBSOLETE category and
On 6/3/2015 5:52 PM, schilpfamily wrote:
i've tried re-installing twice. this was working fine prior to
updating cygwin to latest (which also updated cygwin's version of perl
to the latest).
NOTE: this fails on several of my machines in the same manner (i have
4 build/test machines as well as a
s
is not a machine specific problem
On Wed, Jun 3, 2015 at 11:37 AM, Marco Atzeri wrote:
> On 6/3/2015 5:27 PM, William J. Schilp, PhD wrote:
>>
>> i updated to the latest version of perl on cygwin and i get the
>> following failure:
>>
>> Can't load '
On 6/3/2015 5:27 PM, William J. Schilp, PhD wrote:
i updated to the latest version of perl on cygwin and i get the
following failure:
Can't load '/usr/lib/perl5/5.14/i686-cygwin-threads-64int/auto/IO/IO.dll'
for module IO: No such process at /usr/lib/perl5/5.14/XSLoader.pm line
On Mon, 2015-05-25 at 17:56 -0700, David Rothenberger wrote:
> I've uploaded new versions of libapr1, libaprutil1, and subversion.
> libapr1 is built with threads and the subversion tests appear to pass,
> or at least fail in the same way as with a libapr1 without threads.
Great, th
not even attempted to be built with an APR without threads support.
>>>> While I may be able to get it to compile as-is, I have serious concerns
>>>> that it will not operate as designed, particularly wrt mod_proxy.
>>>>
>>>> What exactly is blocking
Yaakov,
I am looking at providing a tcl-threads package, and it is clear that tcl
has not been built with threads support (configure --enable-threads).
The Threads extension <http://core.tcl.tk/thread> is a standard
part of Tcl 8.6, but it compiles/runs fine with Tcl 8.5 as well
w
Yaakov Selkowitz wrote:
> On Thu, 2015-05-21 at 13:26 -0700, David Rothenberger wrote:
>> Yaakov Selkowitz wrote:
>>> I am looking at upgrading Apache httpd to 2.4, and it is clear that this
>>> has not even attempted to be built with an APR without threads support.
>
On Thu, 2015-05-21 at 13:26 -0700, David Rothenberger wrote:
> Yaakov Selkowitz wrote:
> > I am looking at upgrading Apache httpd to 2.4, and it is clear that this
> > has not even attempted to be built with an APR without threads support.
> > While I may be able to get it to
Yaakov Selkowitz wrote:
> I am looking at upgrading Apache httpd to 2.4, and it is clear that this
> has not even attempted to be built with an APR without threads support.
> While I may be able to get it to compile as-is, I have serious concerns
> that it will not operate
David,
I am looking at upgrading Apache httpd to 2.4, and it is clear that this
has not even attempted to be built with an APR without threads support.
While I may be able to get it to compile as-is, I have serious concerns
that it will not operate as designed, particularly wrt mod_proxy.
What
Mikulas, ping?
On Nov 28 22:12, Corinna Vinschen wrote:
> On Nov 21 15:43, Corinna Vinschen wrote:
> > I'm going to take a step back for now, and reevaluate what happens
> > before trying to apply even more hacks. Ultimately the problem is that
> > the cygtls area is a
On Nov 21 15:43, Corinna Vinschen wrote:
> I'm going to take a step back for now, and reevaluate what happens
> before trying to apply even more hacks. Ultimately the problem is that
> the cygtls area is accessed from other threads (mainly the signal
> thread) without locking, an
On 2014-11-21 14:36, Corinna Vinschen wrote:
On Nov 21 14:06, Yaakov Selkowitz wrote:
On 2014-11-21 10:06, Corinna Vinschen wrote:
On Nov 21 16:50, Marco Atzeri wrote:
On 11/21/2014 3:43 PM, Corinna Vinschen wrote:
On 32-bit. The rebuild of cygwin1.dll requires large number of packages to
cre
On Nov 21 14:06, Yaakov Selkowitz wrote:
> On 2014-11-21 10:06, Corinna Vinschen wrote:
> >On Nov 21 16:50, Marco Atzeri wrote:
> >>On 11/21/2014 3:43 PM, Corinna Vinschen wrote:
> On 32-bit. The rebuild of cygwin1.dll requires large number of packages to
> create the documentation (includi
On 2014-11-21 10:06, Corinna Vinschen wrote:
On Nov 21 16:50, Marco Atzeri wrote:
On 11/21/2014 3:43 PM, Corinna Vinschen wrote:
On 32-bit. The rebuild of cygwin1.dll requires large number of packages to
create the documentation (including tex and java) and I haven't bloated
Java?!?
FOP is
On Nov 21 16:50, Marco Atzeri wrote:
> On 11/21/2014 3:43 PM, Corinna Vinschen wrote:
> >
> >
>
> >>On 32-bit. The rebuild of cygwin1.dll requires large number of packages to
> >>create the documentation (including tex and java) and I haven't bloated
> >
> >Java?!?
>
> make[3]: [cygwin-ug-net/cyg
On 11/21/2014 3:43 PM, Corinna Vinschen wrote:
On 32-bit. The rebuild of cygwin1.dll requires large number of packages to
create the documentation (including tex and java) and I haven't bloated
Java?!?
make[3]: [cygwin-ug-net/cygwin-ug-net.pdf] Error 127 (ignored)
xsltproc --xinclude ../
ther one, which is related to thread_exit. At one point
> > after a couple thousand runs through your testcase I have a variable
> > number of threads hanging in thread_exit, and a timer thread which is
> > unable to send its signal. the other threads all hang in thread_exit,
&g
possible to
build the library without documentation and without such big dependecies.
> I'm testing on 64 bit. I can't reproduce your backtrace, but I can
> reproduce another one, which is related to thread_exit. At one point
> after a couple thousand runs through your testca
On Nov 21 11:15, Corinna Vinschen wrote:
> I can't reproduce your backtrace, but I can reproduce another one, which
> is related to thread_exit. At one point after a couple thousand runs
> through your testcase I have a variable number of threads hanging in
> thread_exit, and a t
t I can reproduce another one, which
is related to thread_exit. At one point after a couple thousand runs
through your testcase I have a variable number of threads hanging in
thread_exit, and a timer thread which is unable to send its signal. the
other threads all hang in thread_exit, waiting for a m
> Never mind that. I can fix your testcase by calling _my_tls.remove with
> INFINITE as parameter in both places. If I drop one of them, your
> testcase will invariable fail at one point. With both INFINITE params
> in place, your testcase is now running half an hour without problems.
For me
On Nov 20 11:00, Corinna Vinschen wrote:
> Hi Mikulas,
>
> On Nov 19 17:42, Mikulas Patocka wrote:
> > Hi
> >
> > I have a program that sets a repetitive timer with setitimer and spawns
> > several threads.
> >
> > The program is very u
Hi Mikulas,
On Nov 19 17:42, Mikulas Patocka wrote:
> Hi
>
> I have a program that sets a repetitive timer with setitimer and spawns
> several threads.
>
> The program is very unstable on cygwin, it locks up in few minutes.
>
> The bug manifests itself in the followin
On Wed, 19 Nov 2014, Mikulas Patocka wrote:
> Hi
>
> I have a program that sets a repetitive timer with setitimer and spawns
> several threads.
>
> The program is very unstable on cygwin, it locks up in few minutes.
This is a simplified example that triggers the lockup ve
Hi
I have a program that sets a repetitive timer with setitimer and spawns
several threads.
The program is very unstable on cygwin, it locks up in few minutes.
The bug manifests itself in the following way: the signal thread calls
cygheap->find_tls to find a thread to deliver the signal
On Oct 28 13:38, Andrew Schulman wrote:
> > Absolutely. Since that's a serious but very subtil error, and you all
> > were very resourceful and diligent helping to fix it, I buy us all a
> > round of goldstars.
>
> Whew.
>
> http://cygwin.com/goldstars/#KB
> http://cygwin.com/goldstars/#KT
> htt
> Absolutely. Since that's a serious but very subtil error, and you all
> were very resourceful and diligent helping to fix it, I buy us all a
> round of goldstars.
Whew.
http://cygwin.com/goldstars/#KB
http://cygwin.com/goldstars/#KT
http://cygwin.com/goldstars/#EZ
http://cygwin.com/goldstars/#
On Oct 28 09:46, Ken Brown wrote:
> On 10/28/2014 7:40 AM, Corinna Vinschen wrote:
> >On Oct 28 10:43, Jon TURNEY wrote:
> >>On 24/10/2014 14:52, Corinna Vinschen wrote:
> >>>I discussed this with my college Kai Tietz (many thanks to him from
> >>>here), and we came up with a problem in sigdelayed
On 10/28/2014 7:40 AM, Corinna Vinschen wrote:
On Oct 28 10:43, Jon TURNEY wrote:
On 24/10/2014 14:52, Corinna Vinschen wrote:
I discussed this with my college Kai Tietz (many thanks to him from
here), and we came up with a problem in sigdelayed in the 64 bit case:
pushf is called *after* align
On Oct 28 10:43, Jon TURNEY wrote:
> On 24/10/2014 14:52, Corinna Vinschen wrote:
> >I discussed this with my college Kai Tietz (many thanks to him from
> >here), and we came up with a problem in sigdelayed in the 64 bit case:
> >pushf is called *after* aligning the stack with andq. This alignment
On 24/10/2014 14:52, Corinna Vinschen wrote:
I discussed this with my college Kai Tietz (many thanks to him from
here), and we came up with a problem in sigdelayed in the 64 bit case:
pushf is called *after* aligning the stack with andq. This alignment
potentially changes the CPU flag values so
On Oct 26 17:38, Ken Brown wrote:
> On 10/26/2014 9:20 AM, Angelo Graziosi wrote:
> >Ken Brown wrote:
> >>The people who have been reporting frequent crashes are aware of the fix.
> >>Now
> >>I just have to wait and hope I don't hear from them for a few days.
> >
> >Just for the record...
> >
> >B
On 10/26/2014 9:20 AM, Angelo Graziosi wrote:
Ken Brown wrote:
The people who have been reporting frequent crashes are aware of the fix. Now
I just have to wait and hope I don't hear from them for a few days.
Just for the record...
Both with the snapshot and test releases, the issues in build
Ken Brown wrote:
The people who have been reporting frequent crashes are aware of the fix. Now I
just have to wait and hope I don't hear from them for a few days.
Just for the record...
Both with the snapshot and test releases, the issues in building Emacs I
had after the migration from Xp+C
On 10/24/2014 9:52 AM, Corinna Vinschen wrote:
On Oct 24 14:54, Corinna Vinschen wrote:
On Oct 24 12:05, Jon TURNEY wrote:
On 23/10/2014 16:37, Corinna Vinschen wrote:
On Oct 23 08:04, Ken Brown wrote:
Yes, flags register corruption is exactly what Eli suggested in the other
bug report I cite
On Oct 24 14:54, Corinna Vinschen wrote:
> On Oct 24 12:05, Jon TURNEY wrote:
> > On 23/10/2014 16:37, Corinna Vinschen wrote:
> > >On Oct 23 08:04, Ken Brown wrote:
> > >>Yes, flags register corruption is exactly what Eli suggested in the other
> > >>bug report I cited.
> > >
> > >The aforemention
On Oct 24 12:05, Jon TURNEY wrote:
> On 23/10/2014 16:37, Corinna Vinschen wrote:
> >On Oct 23 08:04, Ken Brown wrote:
> >>Yes, flags register corruption is exactly what Eli suggested in the other
> >>bug report I cited.
> >
> >The aforementioned patch was supposed to fix this problem and it is
> >
On 23/10/2014 16:37, Corinna Vinschen wrote:
On Oct 23 08:04, Ken Brown wrote:
On 10/23/2014 7:31 AM, Jon TURNEY wrote:
On 20/10/2014 14:03, Ken Brown wrote:
Or is there some other plausible explanation for "impossible" crashes?
This can't just be a result of a gdb bug, because in at least one
On Oct 23 21:07, Ken Brown wrote:
> On 10/23/2014 4:32 PM, Ken Brown wrote:
> >On 10/23/2014 11:37 AM, Corinna Vinschen wrote:
> >>On Oct 23 08:04, Ken Brown wrote:
> >>>On 10/23/2014 7:31 AM, Jon TURNEY wrote:
> On 20/10/2014 14:03, Ken Brown wrote:
> >Or is there some other plausible expl
On 10/23/2014 4:32 PM, Ken Brown wrote:
On 10/23/2014 11:37 AM, Corinna Vinschen wrote:
On Oct 23 08:04, Ken Brown wrote:
On 10/23/2014 7:31 AM, Jon TURNEY wrote:
On 20/10/2014 14:03, Ken Brown wrote:
Or is there some other plausible explanation for "impossible" crashes?
This can't just be a
On 10/23/2014 11:37 AM, Corinna Vinschen wrote:
On Oct 23 08:04, Ken Brown wrote:
On 10/23/2014 7:31 AM, Jon TURNEY wrote:
On 20/10/2014 14:03, Ken Brown wrote:
Or is there some other plausible explanation for "impossible" crashes?
This can't just be a result of a gdb bug, because in at least
Corinna Vinschen writes:
>> Yes, flags register corruption is exactly what Eli suggested in the other
>> bug report I cited.
>
> The aforementioned patch was supposed to fix this problem and it is
> definitely in the current 1.7.32 release...
Emacs uses a bunch of libraries and also messes itself
On Oct 23 08:04, Ken Brown wrote:
> On 10/23/2014 7:31 AM, Jon TURNEY wrote:
> >On 20/10/2014 14:03, Ken Brown wrote:
> >>Or is there some other plausible explanation for "impossible" crashes?
> >>This can't just be a result of a gdb bug, because in at least one case
> >>the assertion can be shown
On 10/23/2014 7:31 AM, Jon TURNEY wrote:
On 20/10/2014 14:03, Ken Brown wrote:
Or is there some other plausible explanation for "impossible" crashes?
This can't just be a result of a gdb bug, because in at least one case
the assertion can be shown to be valid by using printf instead of gdb.
[*]
On 20/10/2014 14:03, Ken Brown wrote:
Or is there some other plausible explanation for "impossible" crashes?
This can't just be a result of a gdb bug, because in at least one case
the assertion can be shown to be valid by using printf instead of gdb.
[*] By "impossible" I mean that examination o
On 10/21/2014 7:17 AM, Corinna Vinschen wrote:
On Oct 20 15:58, Ken Brown wrote:
On 10/20/2014 3:03 PM, Corinna Vinschen wrote:
One of the headaches when porting is sometimes the ABI. While on Linux
the first 6 arguments to a function are given in registers, on Windows
only 4 args are in regis
On Oct 20 15:58, Ken Brown wrote:
> On 10/20/2014 3:03 PM, Corinna Vinschen wrote:
> >One of the headaches when porting is sometimes the ABI. While on Linux
> >the first 6 arguments to a function are given in registers, on Windows
> >only 4 args are in registers. This can result in bugs when call
On 10/20/2014 3:03 PM, Corinna Vinschen wrote:
On Oct 20 18:43, Corinna Vinschen wrote:
On Oct 20 09:03, Ken Brown wrote:
When trying to debug emacs in gdb, I see several threads, but it's not
always clear who created those threads and what they're doing. As an
example, I attached
On Oct 20 18:43, Corinna Vinschen wrote:
> On Oct 20 09:03, Ken Brown wrote:
> > When trying to debug emacs in gdb, I see several threads, but it's not
> > always clear who created those threads and what they're doing. As an
> > example, I attached gdb to an ema
On Oct 20 09:03, Ken Brown wrote:
> When trying to debug emacs in gdb, I see several threads, but it's not
> always clear who created those threads and what they're doing. As an
> example, I attached gdb to an emacs-X11 process (running under X) shortly
> after starting
When trying to debug emacs in gdb, I see several threads, but it's not always
clear who created those threads and what they're doing. As an example, I
attached gdb to an emacs-X11 process (running under X) shortly after starting
it, and I obtained the backtrace appended at the e
;& make install. I'll let you know how it
turns out.No threads/process support in Clisp
--
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
On 05/22/2014 04:26 PM, F. Nikita Thomas wrote:
Hello,
I finally feel confident enough to try processes/threads in Lisp,
however when I evaluate *features* in the repl, I don't see MT:, so no
thread support. Is there a way to rebuild clisp for this
functionality? Clisp version is 2.48, C
Hello,
I finally feel confident enough to try processes/threads in Lisp,
however when I evaluate *features* in the repl, I don't see MT:, so no
thread support. Is there a way to rebuild clisp for this
functionality? Clisp version is 2.48, Cygwin version 1.7.27. Any help
or advice wi
On Thu, Apr 14, 2011 at 07:32:07PM +0100, Andy Koppe wrote:
>I don't know, and the core Cygwin developers appear to be away or too
>busy. Have you tried it?
I'm not away but I have answered this question in the past.
Yes, signals do NOT interrupt interruptible calls in threads.
2011/4/7 Marcin Konarski:
> On Wed, Mar 30, 2011 at 01:52:05PM +0200, Marcin Konarski wrote:
>> Hello list.
>>
>> I have a code that depends on calls that are normally interruptible
>> by signals to be interrupted by signal delivery also in threads.
>>
>>
1 - 100 of 297 matches
Mail list logo
