Alpha to integrity: migration issues

[Saleh AlMaghrabi]

Hi there,
I am migrating an application written in C,C++ and Proc from alpha to integrity. I am facing lots of issues but i am still moving. The last challenge for me was that while reading data from a mailbox and filling a data structure, the number (int) becomes some other value as shown below. On of HP staff told me that in HEX the data appeared to be shifted somehow. I wounder if anyone faced this before. You help is highly appreciated.
------------------------------
expected: 1311220007 is 4E27 A127 (hex)
found:-1591258080 is FFFF FFFF A127 5420 (hex)
------------------------------
expected: 1311220008 4E27 A128
found:-1591192544 A128 5420

the source is attached.
the structures are in STRU.H and the main program is LV2.C

Also, i need to know the values of the following:
&rcvmbx, &akmessinfo what is the best way to print them to the screen.

Yours.

[Hoff]

There certainly looks to be a word-length skew somewhere, or left-over data from a previous message, or differences in padding.

That's a monstrously large and complex pile of code for free advice. If I am reading the code correctly, there are dozens of potential mailboxes here, too. Cut it down, if y'all want us to look at it. And chances are, when you cut all that down to a reproducer, you'll probably find the bug is now gone.

The code in TC_issueMailboxReadRequest and probably in TC_getMessageInformation (and in the remote equivalent) is central to this question, and that doesn't appear to be included. See if what you're getting in that routine matches what you expect, when you hex-dump each message on each end of the mailbox path.

I'd move to state tables here as that makes processing network traffic vastly easier than if-then-else and switch-based message processing, and I'd get the blocks of code around TC_issueMailboxReadRequest into its own processing as there's a whole lot of repeated code there. Refactoring into state tables should simplify the flow of control.

I'd also add the read-sharing option onto the log files open() calls where feasible, rather than that open-close sequence. That's expensive for frequent logging, where sharing avoids what I suspect was the rationale for that implementation. This in the log_l2mess call.

If you're tossing messages around in mailboxes using C I/O, I'd take a very careful look at the results of those calls. C I/O tries to replicate Unix, and which means it can add its own formatting onto the sequences. Using $qio and $qio directly is easier.

I don't see an ASTs (as would be typical for mailbox-based operations), which means that this code is also comparatively synchronous.

There aren't version checks embedded nor version codes in the protocols either, which means you're locked into a specific format for the messages. That works, until you need changes.

All those strlen and strcpy calls mean you're assuming ASCII data and not binary data, too. (They're also unsafe against buffer overflows, but that's another discussion.) I didn't read the code far enough to find out if there's binary data flying or if there are data structures flying, but (if there is) strlen and strcpy will eventually hit a null. Either in the data, or in any padding enabled within the structures.

The code has ODS-2 limits. See home_dir() for what looks like one. I'd also suggest use NAM$C_MAXRSS constant or a local constant or such, rather than the hard-coded 255 magic constant embedded. (And which also looks to have an off-by-one in there with the allocation, too.) The code also assumes ] and not >, and rolling your own filename parsing (rather than using RMS-level file specification parsing) is not something I'd recommend.

strxcpy can probably be replaced with memcpy.

As for troubleshooting this, definitely increase the logging in the read and write routines (if it's not already enabled), and see what's going through that path for each request.

Increase the compiler options. If you're building with /STANDARD=VAXC or are ignoring or suppressing any compiler diagnostics, fix that. Then increase the compiler diagnostics setting to /WARN=WARN=QUESTCODE or analogous.

And I'd definitely look at the structure offsets and any inherent padding within the data structures here, and particularly if you're tossing around C struct stuff within the mailboxes. (VMS doesn't have mechanisms to serialize and deserialize data structures for transport, either, though those can be added.)

My guess? Padding.

[Robert Gezelter]

Saleh,

I will second what Hoff has said, and further note that in addition to the sources, it would be a sound idea to check the compiler options used when compiling all modules.

As Hoff said, this is a bit of a source collection. I agree with Hoff that some form of (likely unintentional) padding is a good candidate for the problem. You may want to have someone with more experience do a deep review of the code [Disclosure: My firm provides such services, as does Hoff and other contributors to this forum].

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

>And I'd definitely look at the structure offsets and any inherent padding within the data structures here...

Including a basic C struct example, details on what I mean by that are here:

http://labs.hoffmanlabs.com/node/1397

Failure to account for padding and alignment within a C data structure is a fairly common problem, and (in addition to the data corruptions discussed in this ITRC thread) accessing unaligned data (frequently) can come with a significant cost to system and to application performance on Integrity.

http://labs.hoffmanlabs.com/node/160

[Hein van den Heuvel]

Read up on


#pragma nomember_alignment
#pragma member_alignment


Just to try... put #pragma nomember_alignment
in the beginning of the H file containing struct from which the data field which has unexepected values is found. That's probably the file defining 'rcvmbx' but I

If that fixes it, then finesse the solution to only force the packed, unnatural alignments around truly unmodifiable structures.

If you need more help from us, then you'll need to provide files which actually defined rcvmbx, and fields like 'msganz'. I See them used, but fail to see a definition.

Good luck!
Hein

[Jess Goodman]

A compiler bug related to the #pragma [no]member_alignment directives is a possibility. Just last week I received a fix from HP support for just such a bug in the IA64 C++ compiler.

I reported this bug just a few weeks earlier, so IMO that was a pretty fast response. The reason they were able to act so quickly is that I sent them source files that they could compile, link, and run that demonstrated the problem.

The source files in your attached .ZIP cannot be compiled because there are many missing #include files. That makes it impossible to reproduce the problem. Please remove as much code as you can can easily do without the problem going away, and send us, or HP support, something we can compile, link, and run.