nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Patch format in CS 16 v previous versions

Jeff Lang

I have a number of patches that fix bugs in core CS. Most of these patches still apply to the code base in CS 16. The problem occurs when I try to load one of these patches, which have been working forever, into CS 16. I get the error "list_cracker() Error - Null byte found in serialized string".

What is the difference in the format between the versions? Was it intentional? Are you now saying that patches created with any version prior to CS 16 will not load? Will patches created with CS 16 work on previous versions of CS?

Here is a snippet from my thread log that shows a patch loading and one failing...

05/18/2016 17:54:41 Applying old format patch: C:\OPENTEXT\CS16\patch\pat160000048.txt
05/18/2016 17:54:41 ....Comment: Patch PAT160000048 created at Mon Apr 04 03:02:24 EDT 2016
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 ....Comment: Issue: LPAD-48290
05/18/2016 17:54:41 ....Comment: Module:
05/18/2016 17:54:41 ....Comment: Version: Content Server 16.0.0 64-bit for Windows
05/18/2016 17:54:41 ....Comment: Update: Initial Release
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 ....Comment: Description:
05/18/2016 17:54:41 ....Comment: Reduce the default number of search results on the Smart UI from 30 to 10
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 ....Comment: Patch included files:
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 ....Comment:    /patch/pat160000048.txt
05/18/2016 17:54:41 ....Comment:    /support/csui/bundles/csui-browse.js
05/18/2016 17:54:41 ....Comment:    /support/csui/bundles/csui-forms.js
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 ....Comment: Installation:
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 ....Comment: 1. Please stop all Content Server services.
05/18/2016 17:54:41 ....Comment: 2. Please make necessary backup before applying the patch.
05/18/2016 17:54:41 ....Comment: 3. Extract patch to Content Server <CSHome> Installation directory.
05/18/2016 17:54:41 ....Comment: 4. Start the content server services.
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 Applying old format patch: C:\OPENTEXT\CS16\patch\pat60366.txt
05/18/2016 17:54:41 ....Comment: Patch PAT60366 created at Mon Mar 28 10:24:53 2016
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 ....Comment: Patch for GCI Power Tools for Deployment V6.1.4 and previous
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 ....Comment: This patch fixes an issue where the full path to the import destination could not be
05/18/2016 17:54:41 ....Comment: determined if that path was in a project.
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 ....Comment:
05/18/2016 17:54:41 list_cracker() Error - Null byte found in serialized string
05/18/2016 17:54:41 KOSValue::FormattedInput() Error - Invalid format.
05/18/2016 17:54:41 #Warning: Object does not exist to overwrite.

Find more posts tagged with

Comments

Kyle_Swidrovich

Jeff,

Why does your pat60366.txt have a null byte in it?

Try opening it up in Notepad++ or TextPad to see where the null byte is.

Kyle

Jeff Lang

It doesn't have a null byte in it. That's just the error message. I determined that the error is caused by the line that specifies the object reference. The o line below:

m {'kernel','gci_deployment'}
o {#105,&gci_deployment[263]}
N Utils
f GetNodeFromPath

When I change that line to:

o {'pat60366::Utils',&&gci_deployment::Utils}

The patch will load correctly. It seems as though the code doesn't understand the old object references. This will become a major problem, for us at least, because we have dozens of patches that work across all previous versions of CS. Having to create special patches for CS 16 will be a royal pain. It seems to me that the code should be backwards compatible.

Kyle_Swidrovich

Jeff,

As with all patches in the past, there is no guarantee that a patch will continue to work from version to version.

While in this particular case, we’re talking about the actual patch directive header, code also needs to be revalidated and adjusted as necessary.

We do our best to keep things as backwards-compatible as possible, but when you’re talking explicit object references (#105) and changes from an old virtual machine to a new virtual machine with modified parsers, compilers and the Oscript language itself, that’s a special edge case that could not reasonably be expected to be kept backwards compatible.

Kyle

Jeff Lang

Kyle,

I'm not sure this is as hard as you're making it out to be. The new compiler still stores object references by numbers, which can be seen in Eclipse when looking at object reference features.

What you are saying for technology partners is that they now have to create multiple versions of any patch they release so that it will work across different versions of CS. This was definitely not the case in the past. Given the fact that we have dozens of patches that correct bugs in CS core and other OT modules, this is going to become a huge burden. I'm sure other technology partners will have the same issue.

Kyle_Swidrovich

Storing static offsets in a patch makes certain assumptions about the compiled structure of the Ospace and how it will be loaded into memory.

This is why references by classpath make more sense within a patch or in code.

Yes, version-specific flavours of a Content Server patch should be created.

OpenText does this when we release patches.

You are correct that this wasn’t the case in the past, however, times have changed that have moved us to the current well-defined structure upon which we’ve built certain features like Cluster Management which admins have been very receptive to.

We are aware that Cluster Management does not yet support non-OpenText patch installations, however, there are ideas to improve upon this.

BTW, have you reported each of the CS core bugs at some point through Customer Support?

If you have a list of bug numbers, I can see where they’re currently sitting within our dev groups.

Thanks,

Kyle

Jeff Lang

Kyle,

I did a bit of research and discovered that the patch code is written to be able to handle both types of patch files. There seems to be a bug in Str.StringToValue that is causing the errors that are being seen and the patches not loaded. If you run the following OScript code in CS pre - 16 and CS 16 you will see the problem:

echo( Str.StringToValue( '{#105,&webuser[15932]}' ) )

echo( Str.StringToValue( '&webuser[15932]' ) )

echo( Str.StringToValue( '#105' ) )

As to reporting the bugs, this forum is not the place to discuss the herculean efforts it takes to navigate support to report an issue and actually get it into a patch or release.

Kyle_Swidrovich

Jeff,

Reporting an issue to support shouldn’t be too difficult.

Well defined issues (especially at a code level) with steps to reproduce are great for reports from support to R&D.

Once it’s in R&D’s hands, it’s a matter of prioritization and scheduling.

I’d be curious to hear why you’ve had so much difficulty.

Please feel free to reach to me directly to discuss further.

Thanks,

Kyle

Jeff Lang

Kyle,

I'll reach out to you separately about reporting issues.

I was able to modify the LLPatch code so that it handles all patch versions. We can use this to continue our QA process for our products, but it won't work for customers. The issue will really need to be fixed in the Str.StringToValue code or changes similar to mine will need to be shipped in an update or patch release. The change was about 5 lines. Let me know if you want them.

BTW

I've discovered that unlocking a legacy ospace in Eclipse with CS 16 causes corruption to the ospace. I'm still tracking it down to find a simple way to reproduce the issue. I've seen it happen on multiple ospaces, so it's not a specific ospace issue.

Jeff

Brian_Funke

Jeff,

One of our contractors discovered that problem in 10.5. He had to export his old ospace in Builder v10. Create a new ospace in eclipse and import the dump from the old version and everything worked fine.

Brian

Chris Meyer

Hi Brian,

He had to export his old ospace in Builder v10. Create a new ospace in eclipse and import the dump from the old version and everything worked fine.

This makes me wonder how many of us are still developing on CS10 Builder and only using the IDE to create compatible binaries.

I hope this and the patch issue gets fixed soon. Both will cause problems for me with some of the products I help manage.

Tammy_Jakubowski

Thanks Brian and Chris for your ospace suggestions. I think a fair number partners/customers are still building/developing in Builder for many reasons, not the least of which is some customers are not ready to upgrade. Our other major reason is that we want to build one version to work across Livelink 9.7.1 through CS 16. We ran into a problem of crash with a non-UTF8 character in ospaces when CS 10.5 came out, but we fixed all of that right away. This is a new problem with CS 16, at least that's what I think so far. We have at least 2 versions(in some cases 6 or 7) of 8 modules that were tested and released against CS 10.5 with no need to import a dumped ospace into a new one.

As far as the object reference issue with patch headers, Jeff Lang found the exact place where the issue was, and wrote a fix for it. We sent that fix to Open Text. We'll end up using the fix for testing, and for our customers if they upgrade to CS 16 before (and if) Open Text integrates that fix or writes their own fix. The ball is now in Open Text's court. I am glad to hear Chris Meyer say that we are not the only ones who'd be affected.

Being an edge case is lonesome. :-)

Tammy

Chris Meyer

Hi Tammy,

Our other major reason is that we want to build one version to work across Livelink 9.7.1 through CS 16.

I'm in the same boat. The maintenance of managing the same product on different versions of Content Server (especially when the IDE differs) is simply too costly and error prone.

But do I understand you're using the same ospace files (i.e., the .oll files) across all CS versions? I tried doing this but lost confidence that CS10.5 could handle this correctly. I now develop in CS10.0 and just use CSIDE 10.5 to recompile the binaries and regression test.

Being an edge case is lonesome. :-)

Jeff Lang

Chris,

We have a dozen different products that we ship and we have the same code and ospaces for all versions of CS. We do all of our development on either 9.7.1 or CS 10 and then we use our custom tool to dump all the module code to SVN. On our build machine, that we actually create the version that goes to the customer, we load the code from SVN and import into a LL 9.7.0 instance to actually create the module along with the ospaces. This is so the ospaces will open with any version of 9.7.1 or later. We've had no problems with CS 10.5 using the same ospaces. CS 16 is the only version we've had issues with.

Jeff

Chris Meyer

Jeff,

Have you done any performance testing using a CS10.0 ospaces on CS10.5? This was one of my biggest problems: I have one module with multiple and complex execution paths (it's a Weblingo template replacement), and performance was terrible until I compiled the binaries on CS10.5.

CS 16 is the only version we've had issues with.

I saw your other thread on this. Have you tried compiling your ospace on CS16 to see if that's the problem?

Chris