A new release of libsigsegv, 2.10-2, will soon be available for download
from your favorite mirror. On 32-bit cygwin, this leaves 2.10-1 as
previous; on 64-bit cygwin, it is a new port of the package, made
possible for the first time by new sigaltstack() code in cygwin 2.1.0.
NEWS:
=
This is
On 01/05/2015 08:28 AM, Marco Atzeri wrote:
> On 1/5/2015 4:12 PM, Eric Blake wrote:
>
>> I'm the libsigsegv maintainer
>
> Hi Eric,
> are you aware of any reason, other than Reini's availability,
> for which we have only the 32 bit libsigsegv package but no
On 1/5/2015 10:28 AM, Marco Atzeri wrote:
On 1/5/2015 4:12 PM, Eric Blake wrote:
I'm the libsigsegv maintainer
Hi Eric,
are you aware of any reason, other than Reini's availability,
for which we have only the 32 bit libsigsegv package but not
the 64bit one ?
https://cygwin.com
On 1/5/2015 4:12 PM, Eric Blake wrote:
I'm the libsigsegv maintainer
Hi Eric,
are you aware of any reason, other than Reini's availability,
for which we have only the 32 bit libsigsegv package but not
the 64bit one ?
Regards
Marco
--
Problem reports: http://cygwin.com/pro
On 3/3/2014 12:06 PM, Corinna Vinschen wrote:
On Mar 3 16:02, Corinna Vinschen wrote:
On Mar 2 12:20, Ken Brown wrote:
[...]
I found the problem (or at least I found *a* problem): There's a
configure test "checking whether a fault handler according to POSIX
works", which passes on 32-bit Cyg
gt; same exception. Proof is that you can remove the second call to crasher
> and still sigsegv_handler gets called twice.
I just created a new snapshot which contains the fix. Would you mind
to test it? It doesn't fix the fact that libsigsegv is missing 64 bit
Windows/Cygwin support, of
On Mar 3 16:15, Kai Tietz wrote:
> Hmm, I think that stuff around EXCEPTION_DEBUG_EVENT is that what you
> are searching for. See for some details
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms679299%28v=vs.85%29.aspx
These are functions for the debugger. I was looking for a way t
Hmm, I think that stuff around EXCEPTION_DEBUG_EVENT is that what you
are searching for. See for some details
http://msdn.microsoft.com/en-us/library/windows/desktop/ms679299%28v=vs.85%29.aspx
Regards,
Kai
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cy
On Mar 2 12:20, Ken Brown wrote:
> On 2/21/2014 10:32 AM, Angelo Graziosi wrote:
> >Trying to build libsigsegv-2.10 on Cygwin64 (using the src tarball and
> >its .cygport file from x86 distribution), fails as follows
> >
> >[...]
> >libtool: compile: gcc -D
On 3/2/2014 12:20 PM, Ken Brown wrote:
On 2/21/2014 10:32 AM, Angelo Graziosi wrote:
Trying to build libsigsegv-2.10 on Cygwin64 (using the src tarball and
its .cygport file from x86 distribution), fails as follows
[...]
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/works/tmp/libsigsegv-2.10-1
On 2/21/2014 10:32 AM, Angelo Graziosi wrote:
Trying to build libsigsegv-2.10 on Cygwin64 (using the src tarball and
its .cygport file from x86 distribution), fails as follows
[...]
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src -I.. -I.
-I
On 2/21/2014 10:46 AM, Corinna Vinschen wrote:
On Feb 21 16:32, Angelo Graziosi wrote:
Trying to build libsigsegv-2.10 on Cygwin64 (using the src tarball
and its .cygport file from x86 distribution), fails as follows
[...]
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/works/tmp/libsigsegv-2.10
On Feb 21 16:32, Angelo Graziosi wrote:
> Trying to build libsigsegv-2.10 on Cygwin64 (using the src tarball
> and its .cygport file from x86 distribution), fails as follows
>
> [...]
> libtool: compile: gcc -DHAVE_CONFIG_H -I.
> -I/works/tmp/libsigsegv-2.10-1/src/libsigseg
Trying to build libsigsegv-2.10 on Cygwin64 (using the src tarball and
its .cygport file from x86 distribution), fails as follows
[...]
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src -I.. -I.
-I/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10
I included Eric Blake's [PATCH] Avoid polluting cygwin namespace,
also at http://repo.or.cz/w/libsigsegv/ericb.git
Successfully tested with clisp.
See http://cygwin.com/ml/cygwin-apps/2011-05/msg0.html
It's a small library for handling page faults in user mode.
A page fault occ
Reini Urban x-ray.at> writes:
> >> The DLL revision is bumped from 1 to 2.
> >
> > I'm curious why you bumped the dll revision when building 2.8. I don't
> > see any backwards-incompatible API changes compared to 2.6 that would have
> > required the bump; am I overlooking something? But the bar
Eric Blake schrieb:
According to Reini Urban on 12/14/2009 10:00 AM:
Eric Blake's SEH chain corruption fixes for libsigsegv on cygwin are now
in the official libsigsegv-2.8 release.
Successfully tested with clisp.
The DLL revision is bumped from 1 to 2.
I'm curious why you bump
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reini Urban on 12/14/2009 10:00 AM:
> Eric Blake's SEH chain corruption fixes for libsigsegv on cygwin are now
> in the official libsigsegv-2.8 release.
> Successfully tested with clisp.
> The DLL revision is bumped
Eric Blake's SEH chain corruption fixes for libsigsegv on cygwin are now
in the official libsigsegv-2.8 release.
Successfully tested with clisp.
The DLL revision is bumped from 1 to 2.
See http://cygwin.com/ml/cygwin/2009-07/msg00881.html
It's a small library for handling page faul
Eric Blake schrieb:
libsigsegv 2.8 was released today, which is the first release that works
out of the box on cygwin (in other words, upstream has now incorporated
all of my patches that prevent libsigsegv from interfering with cygwin's
internal handling of faults). Can we get our distro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
libsigsegv 2.8 was released today, which is the first release that works
out of the box on cygwin (in other words, upstream has now incorporated
all of my patches that prevent libsigsegv from interfering with cygwin's
internal handling of f
Reini Urban wrote:
How can I contact "vvv" from TeX Live to update his instructions?
Gulp! I do not understand "vvv", but today there was some discussion
here[1]: tlbuild AT tug DOT org
The TeXLive web site is: http://www.tug.org/texlive
Cheers,
Angelo.
---
[1]
http://tug.org/pipermail/tl
..
> Oops... Sorry! trying to rebuild the cygwin package, I have downloaded the
> wrong source, libsigsegv-2.6-1-src.tar.bz2 instead of
> libsigsegv-2.6+-1-src.tar.bz2!!
>
> Indeed, now following http://cygwin.com/ml/cygwin/2009-08/msg00760.html, it
> builds!
--
Reini Urban
, libsigsegv-2.6-1-src.tar.bz2 instead of
libsigsegv-2.6+-1-src.tar.bz2!!
Indeed, now following http://cygwin.com/ml/cygwin/2009-08/msg00760.html,
it builds!
Thanks,
Angelo.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation
Reini Urban wrote:
And: Building xindy does not requires clisp src at all!
Really, I am following this:
http://www.tug.org/svn/texlive/trunk/Build/source/utils/README?revision=14527&view=markup
I do not know why they suggest that.
Thanks,
Angelo.
--
Problem reports: http://cygwin.com
2009/8/25 Angelo Graziosi:
> Eric Blake wrote:
>> Yes, you are probably missing the libsigsegv package (with the development
>> headers) and libsigsegv1 package (with the precompiled library), although
>> I didn't check your attachment. And if you MUST rebuild from so
2009/8/25 Eric Blake:
> According to Angelo Graziosi on 8/25/2009 2:35 AM:
>> Eric Blake wrote:
>>> or pull my
>>> patches from:
>>>
>>> git pull git://repo.or.cz/libsigsegv/ericb.git master
>>
>> I have tried, but:
>>
>> $ git
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Angelo Graziosi on 8/25/2009 2:35 AM:
> Eric Blake wrote:
>> or pull my
>> patches from:
>>
>> git pull git://repo.or.cz/libsigsegv/ericb.git master
>
> I have tried, but:
>
> $ git pull git:/
Eric Blake wrote:
or pull my
patches from:
git pull git://repo.or.cz/libsigsegv/ericb.git master
I have tried, but:
$ git pull git://repo.or.cz/libsigsegv/ericb.git master
fatal: Not a git repository (or any of the parent directories): .git
Cheers,
Angelo.
--
Problem reports: http
Eric Blake wrote:
Yes, you are probably missing the libsigsegv package (with the development
headers) and libsigsegv1 package (with the precompiled library), although
I didn't check your attachment. And if you MUST rebuild from source, then
either build from the source package shipped
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Angelo Graziosi on 8/24/2009 3:26 PM:
> The simplest way to reproduce the failure is:
>
> 1. wget http://ftp.gnu.org/gnu/libsigsegv/libsigsegv-2.6.tar.gz
Stock 2.6 is known to be broken when used with cygwin. Don't
I am trying to set up Cygwin-1.7 to build Tex Live, but there is a
failure in building libsigsegv-2.6 (which is needed by Clisp-2.48, which
needs for xindy). I follow the suggestions from Tex Live pages and from
README in TL sources.
On Cygwin-1.5 all works fine.
The simplest way to reproduce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reini Urban on 8/10/2009 6:08 PM:
> Eric,
> Can you please update your git repo at git://repo.or.cz/libsigsegv/ericb.git
> to latest libsigsegv-2.7 so that I can roll a 2.7+
I've rebased my libsigsegv.git repo accordi
Eric,
Can you please update your git repo at git://repo.or.cz/libsigsegv/ericb.git
to latest libsigsegv-2.7 so that I can roll a 2.7+
Or should I rather ignore 2.7 totally? I see no cygwin relevant
changes in 2.7 at all.
Bruno did not include your cygwin fixes for the SEH chain corruption into 2.7
I've promoted the experimental libsigsegv 2.6+-1 to current.
I need it for the upcoming clisp release, though I got no feedback yet
upstream if Eric' fixes will be eventually in the next release 2.7.
Eric Blake fixed the SEH chain corruption in libsigsegv for 2.6+.
The DLL revision is b
Eric Blake fixed the SEH chain corruption in libsigsegv, which is
released hereby as experimental test version 2.6+-1.
The DLL revision is bumped from 0 to 1.
I also fixed the wrong Library category for setup in this and the curr
release.
See http://cygwin.com/ml/cygwin/2009-07/msg00881.html
n stack.
>>
>> I can't grok that sentence. ?Are you reporting a bug?
>
>Sorry, I understood that wrong. I thought Eric reported the bug that
>installing the libsigsegv *stack overflow* handler corrupted the cygwin
>SEH chain with Win2008. Not the *segv* handler.
>
Sorry, I understood that wrong.
I thought Eric reported the bug that installing the libsigsegv *stack
overflow* handler
corrupted the cygwin SEH chain with Win2008. Not the *segv* handler.
But then I learned that indeed a Win2008 exception causes another SEGV
to be delayed
(http://lists.gnu.org/ar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reini Urban on 7/24/2009 11:54 AM:
> clisp started using libsigsegv for 2 purposes:
> 1) sigv handling to enable generational garbage collection (enabled on
> cygwin),
> 2) no-cost stack overflow handling (as with m4, but
On Fri, Jul 24, 2009 at 07:54:50PM +0200, Reini Urban wrote:
>But segv handling is mandatory for decent performance and only
>stack overflow handling corrupts the cygwin stack.
I can't grok that sentence. Are you reporting a bug?
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ
ndocumented "interface" into
>>>>>Cygwin. If we decide to change anything in SEH handler, which we do
>>>>>from time to time, this code is likely to break. We are not likely to
>>>>>keep libsigsegv in mind if we make future changes to the exce
l SEH faults imply
>>>>>SIGSEGV.
>>>>
>>>>The point is that this is using an undocumented "interface" into
>>>>Cygwin. If we decide to change anything in SEH handler, which we do
>>>>from time to time, this code is likely to break
;seems to be ok with a missing sigaltstack function, and some of the code
>tries to work around its lack, there are still lots of places which
>assume that if you're on UNIX you must have this function.
>
>libaltstack is doing something dangerous by assuming that it knows what
li
an undocumented "interface" into
>>> Cygwin. If we decide to change anything in SEH handler, which we do
>> >from time to time, this code is likely to break. We are not likely to
>>> keep libsigsegv in mind if we make future changes to the exception
>>
in. If we decide to change anything in SEH handler, which we do
>>from time to time, this code is likely to break. We are not likely to
>>keep libsigsegv in mind if we make future changes to the exception
>>handler.
>
>Well, this line of argument also leads to the suggestion th
t only uses SEH for stack
>> overflow detection instead of assuming that all SEH faults imply
>> SIGSEGV.
>
> The point is that this is using an undocumented "interface" into Cygwin.
> If we decide to change anything in SEH handler, which we do from time to
> time, this c
4) = faulting_page_address;
> *(unsigned long *)(new_safe_esp + 8) = (unsigned long)
>safe_context;
> return EXCEPTION_CONTINUE_EXECUTION;
>
>
>Another way of looking at this is that libsigsegv implemented its own version
>of sigaltstack; the ideas use
> I'm still mystified as to how a package which uses automatic variables
> to deal with a stack overflow situation could claim to be handling stack
> overflow.
It's all in how Windows generates the stack overflow SEH fault. The comments
in libsigsegv/src/handler-win32
On Thu, Jul 23, 2009 at 06:18:00AM -0600, Eric Blake wrote:
>According to Reini Urban on 7/22/2009 3:55 PM:
>>I've updated libsigsegv to 2.6-1 and added a shared library in
>>libsigsegv0-2.6-1 I hope this solves the SEH corruption issue a little
>>bit, as discussed at h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reini Urban on 7/22/2009 3:55 PM:
> I've updated libsigsegv to 2.6-1 and added a shared library in
> libsigsegv0-2.6-1
> I hope this solves the SEH corruption issue a little bit, as discussed
> at http://cygwin.com/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 7/22/2009 4:26 PM:
>> 2009-07-22 Eric Blake
>>
>> * exceptions.cc (handle_exceptions): Set si_addr according to
>> POSIX for SIGSEGV.
>>
> Looks ok. Please check in.
Done.
- --
Don't work too hard, mak
GFPE, the
>si_addr field is correct, and for all other signals, the si_addr is
>unspecified
>by POSIX so it might as well be the faulting instruction).
>
>Fixing si_addr to contain the correct information will make it possible to
>patch libsigsegv to avoid installing an SEH handler f
I've updated libsigsegv to 2.6-1 and added a shared library in
libsigsegv0-2.6-1
I hope this solves the SEH corruption issue a little bit, as discussed
at http://cygwin.com/ml/cygwin/2009-07/msg00639.html
It's a small library for handling page faults in user mode.
A page fault occ
unspecified
by POSIX so it might as well be the faulting instruction).
Fixing si_addr to contain the correct information will make it possible to
patch libsigsegv to avoid installing an SEH handler for all but stack
overflow. (Without this patch, I think I can still patch libsigsegv to honor
Eric Blake byu.net> writes:
> >> Is there a chance that this represents a bug in
> >> libsigsegv SEH handling that needs to be reported upstream?
> >
> > I'll report that, if it turns out so.
>
> I've already mentioned it to Bruno, and am st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reini Urban on 7/22/2009 2:24 AM:
>> Is there a chance that this represents a bug in
>> libsigsegv SEH handling that needs to be reported upstream?
>
> I'll report that, if it turns out so.
I've already m
ter ();
> main_exception_filter_installed = 1;
> }
> }
>
> It looks like it is installed, never uninstalled. And although the current
> release of libsigsegv is a static-only library, Bruno is proud of the fact
> that
> his libsigsegv package can be provided as a d
On Sat, Jul 18, 2009 at 05:16:51AM -0600, Eric Blake wrote:
>So I see several possibilities:
>[snip]
My point, which I don't think you addressed in your long explanation, is
that there doesn't seem to be any "alternate stack" stuff going on in
the Windows code. Therefore, it seems like you could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 7/18/2009 3:45 AM:
>> AFAICT, the libsigsegv handler is overriding the "myfault" stuff in
>> Cygwin and is causing a fault for something that should be ignored. The
>> "fault&quo
On Jul 18 00:20, Christopher Faylor wrote:
> On Fri, Jul 17, 2009 at 10:55:13PM +, Eric Blake wrote:
> >Eric Blake byu.net> writes:
> >>Of course, given the code, that meant I wasn't using libsigsegv like I
> >>thought I was. So, with my typo corrected, I
On Fri, Jul 17, 2009 at 10:55:13PM +, Eric Blake wrote:
>Eric Blake byu.net> writes:
>>Of course, given the code, that meant I wasn't using libsigsegv like I
>>thought I was. So, with my typo corrected, I'm (unfortunately) still
>>seeing libsigsegv interfere
Eric Blake wrote:
> And I'm not sure what to do in gdb to try and get more useful information:
'step' rather than 'next'. Requires cygwin1.dbg.
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
Eric Blake byu.net> writes:
> Of course, given the code, that meant I wasn't using libsigsegv like I
thought
> I was. So, with my typo corrected, I'm (unfortunately) still seeing
libsigsegv
> interference:
>
> $ ./foo
> fclose -1, errno 9
> Aborted (
Eric Blake byu.net> writes:
> Now, upgrade to the latest snapshot, 20090717.
>
> Without libsigsegv, things operate as before. But with libsigsegv, I now
see...
Aargh. I spoke too soon. For my previous mail, I fat-fingered my command
line, and ended up compiling with:
$ gcc
Eric Blake wrote:
> This post is so cgf can exhale his bated breath from his recent commit:
> That is, libsigsegv no longer causes an unwanted abort. And the latest
> libsigsegv.git package still passes 'make check'. So in other words, it
> looks
> like you fixe
time yet?]
First, the STC:
$ cat foo.c
#include
#include
#include
#include
#ifdef libsigsegv
#include
int
handler (void *addr, int bad)
{
abort ();
}
#endif
void
die ()
{
int i;
i = fclose (stdout);
fprintf (stderr, "fclose %d, errno %d\n", i, errno);
errno = 0;
i = fflush (
lthough the current
release of libsigsegv is a static-only library, Bruno is proud of the fact that
his libsigsegv package can be provided as a dynamic library even on cygwin (in
other words, the current cygwin maintainer of the libsigsegv package could
decide to pass the right configure optio
Reini, thank you for the response.
I have cygwin installed and running (for about an year in this
computer) and I originally installed it using setup.exe. I installed
all the available packages at the time.
Now I'm just trying to get libsigsegv to work. I first followed the
README install
[CC: cygwin - list]
Martin Coria schrieb:
I want to use libsigsegv within CYGWIN and so far I couldn't. I
downloaded and unzipped the binary distribution and manually copied
the files to their respective places. After doing that I tried to
compile one of the example programs that comes wit
I've created and uploaded a new cygwin package libsigsegv-2.4-1
It's a small static library for handling page faults in user mode.
A page fault occurs when a program tries to access to a region of memory
that is currently not available.
It is mainly required to build clisp from sou
70 matches
Mail list logo
