Please Scroll Down to See Forums Below
napsgear
genezapharmateuticals
domestic-supply
puritysourcelabs
UGL OZ
UGFREAK
napsgeargenezapharmateuticals domestic-supplypuritysourcelabsUGL OZUGFREAK

Code or OMGWTFBBQ.... a coding question.

milo hobgoblin

New member
Im having a problem with a particular app and it doesnt make much sense... Im not a coder but maybe you guys can theorize as to why I am having this problem.


Two of the products we use are the orgpublisher plugin which allows us to view org charts within IE6 and of course Acrobat Reader 6.0.

Everything wokrs fine until I install the Acrobat reader 6.0.1.11 patch (upgrading it from 6.0.0.05)

When I close IE from within the orgcharts I get an error

The instruction at "0x00a43e8d" referenced memory at "same address". The memory could not be read.


It does not leave an even in the event viewer. It does not cuase any system instability and all the apps work perfectly. But everytime I close IE from viewing the orgcharts I get this error.

Uninstalling and reinstalling produces the same error.
Running the apps in different order causes the error.
If I reimage the machine... I get the same error in exactly the same register on two different platforms (although the register is different on the D500 vs the 1GHz en-sl... but it always the same register on a specific platform)... the point being its not isolated to a specific platform.


Now I was always under the belief that apps writing to memory registers is completely dynamic and none of these patches are hardware related... so why is it even occuring and why would the registers always be the same??? Shouldnt the app just move the data to the next logical register?

anyways Acrobat and Timevision cant figure it out and point the finger at each other

BTW this is XP sp1 with IE6 sp2

Ive reproduced the cause 3 times now.. its definitely the 6.0.1.11 patch. It does not appear that I can roll back the patch.

Thanks in advance for any advice
 
And you never ever get this message using other apps?

Getting the same memory address usually means bad RAM.
 
Nope only with orgpublisher... and I checked the RAM on two different platofrms... error still happens.

Is it possible that after patching the app that both apps are trying to write to the same register.
 
On a side note, I think while Code knows a lot about computers, his name references cryptography rather than programming.

As for the memory issue, if the problem only happens on one machine but not others, then it is the RAM of that machine.

Technically you could increase the level of error reporting to try to get more info, but it probably wouldn't say "the problem is on line 42 of the uncompiled code where the person declared a string with a length of 400".

If you have the problem on all systems with this setup, then it is just a software conflict. Sounds like the program goes by an outdated API or perhaps there is a corrupt dll, don't know.

The programs are likely both in C++ and therefore have closer access to the memory (whereas if they were VB, it would all by dynamically adjusted and they would have no control for the most part).
It sounds like someone on one of the sides was doing something that was technically not correct, but it ended up with a result that worked - but now there is some communication screw-up on one side after the update and now the problem is exposed.

In the end it doesn't matter much since there probably isn't a lot you can do other than wait for an update from them.

When you say you tried an uninstall and then reinstall and you still have the issue - are you sure you got rid of all instances of it - all dlls, all registry entries, etc?

It does seem odd if you have contacted the actual vendors and they can't reproduce it - usually that points to something on your system - some setup or another program that is non-standard (not necessarily something "out there" but just not the default that their programmers have tested and debugged on).

But yeah, that really doesn't help much - output errors rarely are helpful.
 
100% correct.
While I occasionally wade into actual source code (once a month or so), I don't write code. It's boring work.



OMGWTFBBQ said:
On a side note, I think while Code knows a lot about computers, his name references cryptography rather than programming.

 
well I talked to Timevision again... they were eluding to your logic that Acrobat may be wiritng to an illegal register and the OS is returning an error.


As far as the image builds go... I follow a very specific build in chronological order specifically for this purpose.

No build previous to these (the ones including the Acrobat) update produce this error.

It seems to be specifically related to Acrobats update. And as far as a clean uninstall.. yes I actually went back to a previous image which never had the update and installed it... viola' I get the error.

Timevision thinks the Acrobat may be creating a hook into IE which tries to write to that register... they are using VMWARE at this moment to try and reproduce it.

I hate errors like this... so damn vague.
 
Milo Hobgoblin said:
Nope only with orgpublisher... and I checked the RAM on two different platofrms... error still happens.

Is it possible that after patching the app that both apps are trying to write to the same register.

If it was a RAM issue, then you should be able to reproduce it just by running as much as possible on the machine to fill up the RAM and it would eventually hit that spot and crash.

It is unusual that the two apps would write to the same memory space since you don't usually say "write this to XYZ location" you just say "grab me N more bytes and put this there".

It sounds more like a function that is public in the API is called by the plug-in, but the update has modified that so perhaps now it is no longer public or more likely a member of it isn't public yet it is trying to return that or something.

The issue is very likely that either the Adobe code had a bug in it and they fixed it, or it was fine and the update introduced a bug on their side.
This is then exposed with the plug-in makes a call to it - either trying to pass it data or pull data.

It could also be that if it is trying to pass it data, it is of size X, but the new code has a new limit on that data (usually happens when they are trying to prevent buffer overflows but don't then dynamically allocate the memory properly).

But yeah, there is really not much I can say to help other than I don't really know.
 
The timevision dev said something pretty close to that...

Fucking Acrobat is useless and doesnt want to help.


well thanks for the opinions anyways. Hopefully this headache will go away before it turns into a tumor.
 
I would think it is *much* more likely that Adobe Acrobat is to blame on this one since it worked prior to the update.

That said, the last option that I can think of would be a fault on both sides. But it is really nearly impossible by my estimate.

That would be if Adobe doesn't want the other software to do something - but the other guys get around it.
If they discovered that Adobe usually keeps track of data in a certain spot (like I said, very unlikely), then they could get around limitations (say Adobe doesn't usually let you make a chart that is blue for some reason), but editing that spot in the memory.
If Adobe then changed it so that something else was in that spot, editing it would then feasibly break it.

All of that is so very likely wrong on so many levels that I really wouldn't expect that to be the answer.

It would be much more likely one of the other things I mentioned I think.

This is all stuff that you see in C more so even than C++ - perhaps the app is written in C. Likely a mix - the UI is C++ and the stuff that needs to be fast in C.

bah - annoying stuff and hard to guess at without seeing the code
 
Top Bottom