Discussion:
[omniORB] compiling omniORB-4.0.7 on XP -- Assertion failure
Aida Fátima Cano
2006-12-05 14:47:18 UTC
Permalink
Hello

I've read this message

*Sun, 31 Oct 1999 21:54:02 -0500*

- Next message: [omniORB] compiling omniORB3 on NT -- Assertion
failure
<http://www.omniorb-support.com/pipermail/omniorb-list/1999-November/014105.html>

posted some years ago and I've realized this is the same problem I have with
the OmniORB-4.0.7 release when using under windows XP.

You can find it here:
http://www.omniorb-support.com/pipermail/omniorb-list/1999-November/014089.html

Could somebody tell me if really it has not been fixed since then or if
another release release works fine at this point?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20061205/1a51a16f/attachment.htm
Duncan Grisby
2006-12-05 21:21:19 UTC
Permalink
Post by Aida Fátima Cano
I've read this message
*Sun, 31 Oct 1999 21:54:02 -0500*
- Next message: [omniORB] compiling omniORB3 on NT -- Assertion failure
<http://www.omniorb-support.com/pipermail/omniorb-list/1999-November/014105.html>
posted some years ago and I've realized this is the same problem I have with
the OmniORB-4.0.7 release when using under windows XP.
Exactly what problem do you have? Are you just encountering the
well-documented limitation with mixing debug and non-debug Windows DLLs?
You need to make sure that you use matched debug options between omniORB
DLLs and your application code.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
OKeeffe, Michael K
2006-12-05 21:29:20 UTC
Permalink
But if you follow the threads, it seems Ji-Yong's issue was mixing versions (debug/static and static/dll):

"I linked Microsoft static run-time library against omniNames.exe, =
but I linked omniORB3 and omniDynamic3 against run-time dynamic =
libraries. It seems that this was causing problems. Apparently, all =
linkages must be performed against dynamic libraries or all must be =
linked against static libraries..

This likely was the cause of creating multiple heaps and the =
assertion failure. (I have not had opportunities to check things out =
fully, but this is the most likely thing -- of course, if not, then, I =
will have to retract my apology).

I suppose the MSVC's assertion failure did point out the problem -- =
only the problem turned out to be mine. Basically, I had to reset the =
linker options so that ALL modules linked against MSVCRTD.DLL."

http://www.omniorb-support.com/pipermail/omniorb-list/1999-November/014094.html

These e-mails suggest the same:
http://www.omniorb-support.com/pipermail/omniorb-list/1999-November/014110.html

http://www.omniorb-support.com/pipermail/omniorb-list/1999-December/014404.html



-----Original Message-----
From: omniorb-list-***@omniorb-support.com [mailto:omniorb-list-***@omniorb-support.com] On Behalf Of Aida F?tima Cano
Sent: Tuesday, December 05, 2006 2:47 AM
To: omniORB-***@omniorb-support.com
Subject: [omniORB] compiling omniORB-4.0.7 on XP -- Assertion failure


Hello

I've read this message

Sun, 31 Oct 1999 21:54:02 -0500

* Next message: [omniORB] compiling omniORB3 on NT -- Assertion failure <http://www.omniorb-support.com/pipermail/omniorb-list/1999-November/014105.html>

posted some years ago and I've realized this is the same problem I have with the OmniORB-4.0.7 release when using under windows XP.

You can find it here: http://www.omniorb-support.com/pipermail/omniorb-list/1999-November/014089.html

Could somebody tell me if really it has not been fixed since then or if another release release works fine at this point?

Thanks




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20061205/b499261f/attachment.htm
Aida Fátima Cano
2006-12-08 18:54:20 UTC
Permalink
I' ve changed to the new release (4.1.0 RC2), and it seems it works. Now I
can run mi project in debug mode under windows XP without read and write
access violations, and it dosen't throw "heap" exceptions.

I just thought the 4.0.7 release had no inline definitions, cause all I read
about those errors was relted with the omniORB-3 release.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20061208/f55eb1f5/attachment.htm
Meding, Olaf
2006-12-08 23:04:21 UTC
Permalink
Do I really have to manually delete the name service log file (and it's
backup file) EVERY time I start the name service?

Here are the commands I use to start the name service:
set OMNINAMES_LOGDIR=C:\temp\omniorb
omninames -start

Here is the error I get:
Error: log file 'C:\temp\omniorb\omninames-MEDING.log' exists. Can't
use -start option.

Worse, after I deleted the .log file I get another error:
Error: backup file 'C:\temp\omniorb\omninames-MEDING.bak' exists.
Can't use -start option.


Secondly, the name service refuses to start if the log directory does
not exist, why can't the name service just automatically create the
directory?

I am using omniORB 4.1.0 (compiled with VC7) on Windows XP.

Olaf
JHJE (Jan Holst Jensen)
2006-12-08 23:51:27 UTC
Permalink
Post by Meding, Olaf
Do I really have to manually delete the name service log file
(and it's
backup file) EVERY time I start the name service?
set OMNINAMES_LOGDIR=C:\temp\omniorb
omninames -start
Hi Olaf.

You should only use '-start' the first time you start omniNames. It
actually says so when you start it with incorrect parameters:

usage: omniNames [-start [<port>]]
[-logdir <directory name>]
[-errlog <file name>]
[-ignoreport]
[<omniORB-options>...]

Use -start option to start omniNames for the first time.
...
...

Would of course be nice if the omniNames doc said so as well.
Post by Meding, Olaf
Secondly, the name service refuses to start if the log directory does
not exist, why can't the name service just automatically create the
directory?
I suppose so, but consider the case where you have misconfigured (e.g.
copy/pasted a configuration from another server) and omniNames starts
creating and writing to a wrong location... For a server-side piece of
software I prefer the current behavior - the least surprising.

Cheers
-- Jan Holst Jensen, Denmark

Loading...