On Feb 8 14:55, Heiko Elger wrote: > Corinna Vinschen writes: > > > > So why I will get this error - only cause of symantec? > > > > Perhaps. Probably. I'm not sure. However, the above addresses > > 0xC1A000 and 0xA6A000 are *very* unlikely DLL load addresses in a > > Windows system. Usually DLLs are loaded at addresses beyond > > 0x10000000, preferredly to the address stored in the DLL header. > > As I said , I don't no if SEP is really the culprit here, but at > > least the address are weird. And... > > Is this perhaps same problem or a side effect as discussed in in > http://thread.gmane.org/gmane.os.cygwin/131027/focus=131095?
There is a ML archive at http://cygwin.com/ml/cygwin/ too. I'd prefer to use that since it's the ultimate source ;) But, no, to the best of my knowledge that's not the same problem. What you see is apparently a BLODA problem. > > The code checks if the data and bss segments of a given DLL, which was > > already loaded by the parent process, is in the same spot in the child > > process. If not, the DLL has been loaded into another address in the > > child, which will likely result in a nonfunctional forked process. > > Can you tell me where this checking is done. dll_init.cc, method dll_list::alloc. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
