Hello!
I have got the problem, that I can‘t read from a serial port without writing at
least one byte to it before.
Another workaround is to use an terminal application (I tried with HTerm) and
connect (and then disconnect again) to the COM port, this seems to fix it for
the next run.
Closing t
Hi,
I have the problem that I get a segmentation fault on the newer versions of the
cygwin1.dll when debugging and a STATUS_STACK_OVERFLOW exception when running
without debugger.
I did an update of my cygwin stuff on Monday, and I'm using the latest snapshot
dll. I'm quite sure it has somethin
NOSORT, NULL, &info );
printf("Found %d files.\n", info.gl_matchc);
for (i=0; i -Original Message-
> From: Corinna Vinschen
> Sent: Tuesday, February 07, 2012 5:46 PM
> Subject: Re: cygwin > 1.7.9: Segmentation faults / STATUS_STACK_OVERFLOW
>
> On F
Hi Corinna,
thanks for the info about the stack sizes.
> [...]
> pthread_attr_t attr;
> pthread_attr_init (&attr);
> pthread_attr_setstacksize (&attr, 1024 * 1024);
>
> ret = pthread_create(&threadId, &attr, callGlob, NULL);
> [...]
Jep, that works for me.
Manuel
Hi,
I noticed that I get a permission denied error when I try to open a message
queue in the same process or
in an other process.
The problem can be reproduced using the code given at:
http://sourceware.org/ml/cygwin/2009-09/msg00629.html
I tried several versions:
1.7.7 (from the installer): per
Hi,
I have the following problem. When I install a signal handler and unblock the
according signal in one thread, system calls in other threads will be
interrupted, although the signal is blocked or ignored in those other threads.
Regards,
Manuel
Btw: Thanks Corinna for the ultra fast bugfix
Hi,
any suggestions? Can anyone confirm the problem (at least for me the behavior
is unexpected...)?
Regards,
Manuel
-Last message-
Hi,
I have the following problem. When I install a signal handler and unblock the
according signal in one thread, system calls in other threads will b
Hi,
I have a problem with the mqueues.
If I use mq_timedreceive() and do not set O_NONBLOCK, mq_timedreceive() blocks
forever and eats 100% of one cpu core.
If I use mq_receive() and set O_NONBLOCK, mq_receive() blocks forever (0% cpu).
Thanks,
Manuel
Here is some test code:
#include
#inclu
m: Corinna Vinschen
> Sent: Thursday, March 03, 2011 5:32 PM
>
> On Mar 3 12:13, Corinna Vinschen wrote:
> > On Mar 3 10:57, Manuel Wienand wrote:
> > > Hi,
> > >
> > > I have a problem with the mqueues.
> > > If I use mq_timedreceive() and do no
Hallo,
it seems that mq_unlink and/or mq_open forget to close some handles (5 to be
precise).
How to test:
Execute the following code and watch the number of handles in the windows
task-manager (processes tab, you can add a column there). For me it increases
by 5 with every loop.
Tested with t
Grmpf,
sorry for the spam. Just realized that mq_close is still needed, even if we
don't want to open the queue again.
mq_unlink just deletes the file while mq_close frees the resources of the mqd_t
struct.
Manuel
> -Original Message-
> Sent: Monday, April 04, 2011 2:50 PM
> Subject:
Hallo,
it seems that spawning a process brakes the reopening of a serial port (when
done during the execution of that process). The result of the open() function
is "Permission denied (13)" in that case.
How to test:
Run the following code ;)
TestSharedMemProc is the process that should be spaw
D_SPORADIC) and directory streams are passed down
Is that correct?
Thanks
Manuel
> -Original Message-
> From: *** On Behalf Of Corinna Vinschen
> Sent: Friday, October 21, 2011 12:50 PM
> To: ***
> Subject: Re: 1.7.9: spawn brakes reopening of serial port
>
> On Oct 20 10
13 matches
Mail list logo
