On 02/03/2018 09:14, ignace danneels wrote:
I’m very sorry to contact you, but I may need some support to solve
the following problem.
My company is creating automotive software, and our controllers are
using a bootloader which we buy from an external supplier.
In general on this mailing list,
On 7/18/2012 11:38 AM, Earnie Boyd wrote:
On Wed, Jul 18, 2012 at 2:15 PM, Andrew DeFaria wrote:
Odd. Somebody seems to have put something in my Views directory - a
directory I normally use for Clearcase views. But what's in there is not a
Clearcase view! And it contained several cygwin1.dll's.
On Wed, Jul 18, 2012 at 2:15 PM, Andrew DeFaria wrote:
> Odd. Somebody seems to have put something in my Views directory - a
> directory I normally use for Clearcase views. But what's in there is not a
> Clearcase view! And it contained several cygwin1.dll's. So I blew it way.
> Sorry for the confu
On 7/18/2012 8:04 AM, Reini Urban wrote:
On Tue, Jul 17, 2012 at 9:37 PM, Andrew DeFaria wrote:
On 7/17/2012 6:56 PM, Reini Urban wrote:
On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote:
Is there a workaround for the problem mentioned in
http://cygwin.com/ml/cygwin/2006-11/msg00580.html?
On Tue, Jul 17, 2012 at 9:37 PM, Andrew DeFaria wrote:
> On 7/17/2012 6:56 PM, Reini Urban wrote:
>> On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote:
>>>
>>> Is there a workaround for the problem mentioned in
>>> http://cygwin.com/ml/cygwin/2006-11/msg00580.html? I suddenly started
>>> getti
On 7/17/2012 6:56 PM, Reini Urban wrote:
On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote:
Is there a workaround for the problem mentioned in
http://cygwin.com/ml/cygwin/2006-11/msg00580.html? I suddenly started
getting this error like every other time I run perl.
perlrebase
When I run pe
On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote:
> Is there a workaround for the problem mentioned in
> http://cygwin.com/ml/cygwin/2006-11/msg00580.html? I suddenly started
> getting this error like every other time I run perl.
perlrebase
--
Problem reports: http://cygwin.com/problem
On 3/2/2012 3:59 AM, Corinna Vinschen wrote:
> On Mar 1 17:44, Charles Wilson wrote:
>> Is there some workaround that could be used?
>
> Rebase pghook.dll.
Oh, well, yeah -- that would work if I were allowed to do so. However,
remember "paranoid corporate IT policies"? Avecto Privilege Guard i
On Mar 1 17:44, Charles Wilson wrote:
> On 3/1/2012 7:14 AM, Corinna Vinschen wrote:
> > Hmm. cygcheck loads the Cygwin DLL dynamically. It does not depend on
> > any other Cygwin distro DLL. But it's started from a Cygwin parent. So
> > the loaded CYgwin DLL checks the layout just like it had
On 3/1/2012 7:14 AM, Corinna Vinschen wrote:
> Hmm. cygcheck loads the Cygwin DLL dynamically. It does not depend on
> any other Cygwin distro DLL. But it's started from a Cygwin parent. So
> the loaded CYgwin DLL checks the layout just like it had been linked
> against. And apparently it gets
On Mar 1 11:59, marco atzeri wrote:
> On Thu, Mar 1, 2012 at 11:51 AM, Corinna Vinschen wrote:
> > On Feb 29 14:30, Charles Wilson wrote:
> >> I've been running into a strange "error" lately (that is, I first
> >> noticed it for sure on 1.7.10, but it MIGHT have occurred also on 1.7.9.
> >> It per
On Thu, Mar 1, 2012 at 11:51 AM, Corinna Vinschen wrote:
> On Feb 29 14:30, Charles Wilson wrote:
>> I've been running into a strange "error" lately (that is, I first
>> noticed it for sure on 1.7.10, but it MIGHT have occurred also on 1.7.9.
>> It persists on 1.7.11). cygcheck -- and *only* cygche
On Feb 29 14:30, Charles Wilson wrote:
> I've been running into a strange "error" lately (that is, I first
> noticed it for sure on 1.7.10, but it MIGHT have occurred also on 1.7.9.
> It persists on 1.7.11). cygcheck -- and *only* cygcheck -- is reporting
> a cygheap base mismatch but only on an XP
On Mar 1 05:56, Heiko Elger wrote:
> I can agree having some times same error on multiple machines (win7/64) - but
> always when running perl.
>
> 1 [main] perl (7796) c:\programme\cygwin\bin\perl.exe: *** fatal error -
> cygheap base mismatch detected - 0xE158D0
> /0xEF58D0.
I don't know what
On Thu, Mar 1, 2012 at 6:56 AM, Heiko Elger wrote:
> I can agree having some times same error on multiple machines (win7/64) - but
> always when running perl.
>
> 1 [main] perl (7796) c:\programme\cygwin\bin\perl.exe: *** fatal error -
> cygheap base mismatch detected - 0xE158D0
> /0xEF58D0.
> Thi
I can agree having some times same error on multiple machines (win7/64) - but
always when running perl.
1 [main] perl (7796) c:\programme\cygwin\bin\perl.exe: *** fatal error -
cygheap base mismatch detected - 0xE158D0
/0xEF58D0.
This problem is probably due to using incompatible versions of the
On 2/29/2012 8:30 PM, Charles Wilson wrote:
I've been running into a strange "error" lately (that is, I first
noticed it for sure on 1.7.10, but it MIGHT have occurred also on 1.7.9.
It persists on 1.7.11). cygcheck -- and *only* cygcheck -- is reporting
a cygheap base mismatch but only on an XP6
On Nov 22 12:36, Joseph Koenig wrote:
> Congrats on figuring the problem out so quickly. Forgive my lack of
> familiarity with the cygwin development process (and cygwin in general),
> but as you've seemingly isolated root cause, do you feel that a point
> fix should be forthcoming shortly or do yo
a Vinschen
Sent: Wednesday, November 22, 2006 5:04 AM
To: cygwin@cygwin.com
Subject: Re: cygheap base mismatch detected - only on Vista x64, not
seen on Vista x86
On Nov 17 18:29, Joseph Koenig wrote:
> DISCLAIMER: Yes, I realize Vista is not officially supported. If
anything I hope this e-mail
On Nov 17 18:29, Joseph Koenig wrote:
> DISCLAIMER: Yes, I realize Vista is not officially supported. If anything I
> hope this e-mail will end up in the archives to prevent other uses who see
> this same problem from wasting time if there is no war available.
>
> I have successfully used cygwi
On 11/17/2006, Joseph Koenig wrote:
Has anyone seen a similar error? Has anyone got a clue as to WAR? Perhaps a
rebase? I have tried disabling DEP for bash and ls as I am worried about
address space randomization causing problems with fork, but that exists in
Vista32 and I don't have problems o
On Fri, Feb 24, 2006 at 02:36:19PM -0600, Dill, Jens wrote:
> I did make the changes to rebase suggested by Mark Geisert, and I will
> be forwarding my updated source file to Jason Tishler for him to take
> a look at.
Please send them in the form of a patch against the latest source.
Thanks,
Jaso
I'm happy to report that I was finally able to run a
successful "rebaseall" (after tracking down and stopping
the pesky service that was using Oracle DLLs and restarting
itself every time I killed it in the Task Manager).
Now that the Oracle DLLs have been rebased, the app runs.
I'm now into other
On Sat, Feb 18, 2006 at 09:12:02PM -0600, Dill, Jens (END-CHI) wrote:
> It seems that there is indeed more to it. I did make the "obvious"
> change and reran rebaseall. The message I got from the first Oracle
> DLL it encountered was:
>
> ReBaseImage (/cygdrive/d/oracle/app/oracle/product/9.2.
On Tue, Feb 21, 2006 at 11:18:40AM -0800, Yitzchak Scott-Thoennes wrote:
> Jason, are you following this?
Not very closely. Sorry, but cycles are very scarce right now.
However, I did note the following from Mark:
On Sat, Feb 18, 2006 at 01:39:30AM -0800, Mark Geisert wrote:
> The code at /src/
Jason, are you following this?
On Sat, Feb 18, 2006 at 09:12:02PM -0600, Dill, Jens (END-CHI) wrote:
> We are finally zeroing in on the problem.
>
> Mark Geisert writes:
> > The code at /src/rebase-2.3.1/rebase.c:255 assumes the signature is at
> offset 0x80
> > in the image. This was true in th
On Tue, Feb 21, 2006 at 09:25:45AM -0600, Dill, Jens (END-CHI) wrote:
> (2) Rebase the CygWin DLL so that it loads by default into a
> space not used in either memory map (I'd need help in
> choosing such a space). I've tried both Microsoft's
> rebase and CygWin's rebase, but the
Brian Dessent writes:
>I think your best bet would be to keep poking at rebase to see if you
>can't actually rebase the Oracle DLLs.
>
>> (2) Rebase the CygWin DLL so that it loads by default into a
>> space not used in either memory map (I'd need help in
>> choosing such a space). I've
"Dill, Jens (END-CHI)" wrote:
> I have found Microsoft's Platform SDK, and have used the VaDump utility
> to find out where all the DLL's are loaded. Here is what it says about
> my app (sorted into ascending order of memory address):
FYI, to check the ImageBase of a given DLL you can just use o
Mark Geisert writes:
> >I can't do more without learning a lot more than I currently know
> >about the internals of DLLs and of rebase.
>
> You have the "problem" Oracle DLLs, we don't :-) so you might be the
> only one who can ultimately solve the problem. But see below...
Right. But you (colle
On Sun, Feb 19, 2006 at 09:02:10PM -0800, Mark Geisert wrote:
>Forgive me for possibly reading more into your text than you intended
>and thus responding inappropriately, but, Cygwin is an all-volunteer
>and essentially non-managed project. (No offense Christopher :-) There
>are no *guarantees* ab
On Sat, 18 Feb 2006, Dill, Jens (END-CHI) wrote:
[...]
I finally found where to get the rebase source, and verified that in
fact, what Mark noticed in 2.3.1 is still true in 2.4.2-1. I can
easily make the obvious fix and change the is_rebaseable function to
get the pe_signature_offset out of p
On Sat, Feb 18, 2006 at 09:12:02PM -0600, Dill, Jens (END-CHI) wrote:
> So, I have a workaround of sorts. I can have my script launch my app
> by writing the command line to a .bat file and executing it. Definitely
> not something I can use to convince my management to go with CygWin.
Wouldn't j
We are finally zeroing in on the problem.
Mark Geisert writes:
> The code at /src/rebase-2.3.1/rebase.c:255 assumes the signature is at
offset 0x80
> in the image. This was true in the early Windows days but has long since
been
> generalized. The technique nowadays is to obtain the short integer
On Fri, 17 Feb 2006, Dill, Jens (END-CHI) wrote:
[...]
I did try rebaseall. It told me all the Oracle DLLs were not
rebaseable. The -v output is included below.
[...]
/usr/bin/tclpip84.dll: skipped because not rebaseable
/usr/share/terminfo/a/ansi+sgrso: skipped because not rebaseable
/usr/s
I wrote:
> Could I
> "fix" the problem by providing a stripped-down app that links all
> the DLLs and and all the same static libraries, but does nothing
> but launch a shell, which can then be used to launch the real app?
Nope, didn't work. Got the same message:
2 [main] ? (-5768) d:\m1\voy
Dave Korn wrote
>On 17 February 2006 19:21, Brian Dessent wrote:
>
>> Dave Korn wrote:
>>
>>> Absolutely so. I reckon doing a proper rebaseall that includes the
>>> oracle dlls should make a noticeable difference.
>>
>> This is important. The rebaseall script only knows about DLLs installed
>
Dave Korn writes:
> Right, thanks for giving us something we can actually get our teeth
into...
> it would really have been helpful to bring out some of this information a
bit
> earlier in the thread, like in the very first post for instance, but
better
> late than never!
Sorry I didn't send con
On 16 February 2006 23:17, Dill, Jens (END-CHI) wrote:
> More test results:
Right, thanks for giving us something we can actually get our teeth into...
it would really have been helpful to bring out some of this information a bit
earlier in the thread, like in the very first post for instance,
More test results:
> I can run tests in which I allocate static arrays of increasingly
> large size, and I hit the cygheap base problem *exactly* when I
> try to make an array bigger than 1.5 Gb.
This still happens reliably, and note that I can declare an array
of *exactly* 1.5 Gb, and load and r
Dill, Jens (END-CHI) wrote:
Dave Korn writes:
Unfortunately for me, (e) is impractical. It's not clear whether
it is my source code or CygWin's that I need to fix,
Have you actually *tried* this application of yours under Cygwin and
discovered that it indeed *is* one of the rare ones that a
On 16 February 2006 18:03, Dill, Jens (END-CHI) wrote:
> I can't make this agree with the facts in front of me.
>
> If it has to do with executables that allocate massive amounts
> of heap space, then how does the message appear before the
> application even starts, before it has a chance to allo
Dave Korn writes:
> > Unfortunately for me, (e) is impractical. It's not clear whether
> > it is my source code or CygWin's that I need to fix,
>
> Have you actually *tried* this application of yours under Cygwin and
> discovered that it indeed *is* one of the rare ones that actually runs
into
Dave Korn writes:
> On 15 February 2006 22:23, Jens Dill wrote:
>
> Jens Dill writes:
> >
> >> Original Message
> >>> From: Andreas Heckel
> >>> Sent: 07 April 2005 11:13
> ^
> > Dave:
> >
> > What you write makes it appear that CygWin simply will not support
> > la
On 16 February 2006 07:17, Dill, Jens (END-CHI) wrote:
> Unfortunately for me, (e) is impractical. It's not clear whether
> it is my source code or CygWin's that I need to fix,
Have you actually *tried* this application of yours under Cygwin and
discovered that it indeed *is* one of the rare
On Thu, Feb 16, 2006 at 01:17:07AM -0600, Dill, Jens (END-CHI) wrote:
>Christopher Faylor wrote:
>> On Wed, Feb 15, 2006 at 10:22:30PM +, Jens Dill wrote:
>> >What you write makes it appear that CygWin simply will not support
>> >large executables that reference the CygWin DLL and are also laun
On 15 February 2006 22:23, Jens Dill wrote:
> Dave Korn artimi.com> writes:
>
>>
>> Original Message
>>> From: Andreas Heckel
>>> Sent: 07 April 2005 11:13
^
> Dave:
>
> What you write makes it appear that CygWin simply will not support
> large executables that re
Christopher Faylor wrote:
> On Wed, Feb 15, 2006 at 10:22:30PM +, Jens Dill wrote:
> >What you write makes it appear that CygWin simply will not support
> >large executables that reference the CygWin DLL and are also launched
> >from a CygWin shell. I can't believe that nobody has found a bett
On Wed, Feb 15, 2006 at 10:22:30PM +, Jens Dill wrote:
>What you write makes it appear that CygWin simply will not support
>large executables that reference the CygWin DLL and are also launched
>from a CygWin shell. I can't believe that nobody has found a better
>workaround than:
>
> (a) not
Dave Korn artimi.com> writes:
>
> Original Message
> >From: Andreas Heckel
> >Sent: 07 April 2005 11:13
>
> > Since I read that the error has something do with putting the cygwin1.dll
> > in a certain memory space, I am wondering, if my prog is allocating too
> > much memory (big array
Hi,
- Original Message -
From: "Mark Hadfield" <[EMAIL PROTECTED]>
The solutions:
- Try the -mno-cygwin switch (thus creating a non-Cygwin executable).
Be aware that you may need to recompile any external libraries.
I tried this and it works for now, Thanx! :-) I should have come t
Andreas Heckel wrote:
Hello all,
I know there were a lot of similar questions to this point in the past,
but I didn't find a answer to my problem:
I get the error message:
---
v:\julian\TRAJ\Traj2.xi686 (2116): *** cygheap base mismatch detected -
0x6180/0x7214.
This problem is probably
Original Message
>From: Andreas Heckel
>Sent: 07 April 2005 11:13
> Since I read that the error has something do with putting the cygwin1.dll
> in a certain memory space, I am wondering, if my prog is allocating too
> much memory (big arrays) or in "bad way".
> I am not an expert in these
53 matches
Mail list logo
