Pagestream4 Crash and MuForce Hit in 3.1.4

[my_pc_is_amiga]

I'm attaching a MuForce hit.  In Pagestream, I do a copy of a large object (group that includes text and graphics).  The Clipboard shows 542,270 bytes of data.   Copy goes okay.  When I do a Paste in Pagestream I get the hit.   If anybody knows any workaround or what the issue could be from the log, please let me know.  I'll probably try with an increase in the stack.  Would be nice to see Pagestream development come back to life again ...

I don't know if this 3.1.4 specific or not.

[Pyromania]

It would be nice to see Pagestream development come back again. Hope springs eternal, it was such a great DTP package for many years.

[my_pc_is_amiga]

I loaded up OS3.9 env. and then did the same copy/paste operation in Pagestream and the paste went through -- no hang.   

I'll have to see if I can use a Loadmodule in 3.1.4 of the older clipboard.device to see if any issue.   

[my_pc_is_amiga]

Oops … forgot clipboard.device is on disk.  Anyways, I tired it with v38.8 in 3.1.4 and it worked!   

[my_pc_is_amiga]

I now tried clipboard.device in 38.4 in FinalWriter.  This works but with 45.3, it doesn't.

For the FinalWriter case, there is no MuForce hit.   Instead, I get a flashing screen upon pasting.   How to reproduce in FinalWriter:

1) Import Object --> import a large IFF picture (in my case it was a 821k)
2) Do a "Copy"
3) Do a "Paste" --> screen flashes and object does not get pasted.   In 38.4 it does.

For Pagestream, when I do a copy and then paste of a large object, it does give me MuForce / MuGa hit.

[guest11527]

Thanks for reporting. I did some research on this. It seems that an arithmetic overflow in the clipboard is responsible for this, so this is likely going to be fixed in the next release.

[my_pc_is_amiga]

Great, thanks!  Any likelihood of a maintenance release before 3.2?  Like a 3.1.4.1.1 (or however it would be called)

[my_pc_is_amiga]

I'm attaching a separate hit that I'm seeing in pagestream.  This hit is coming from loading a pagestream document.   Not sure if size related but have been loading 16MB and 43MB document files (which contain lots of pictures).

And I don't know if OS component or Pagestream causing issue. I'm running in 3.1.4.1 OS env.

[guest11527]

I'm attaching a separate hit that I'm seeing in pagestream.  This hit is coming from loading a pagestream document.   Not sure if size related but have been loading 16MB and 43MB document files (which contain lots of pictures).

There is not much to learn here. All I can say is that there is an "off-by-one" error in one of the involved components, though without further information, one cannot say. This is a MuGA hit, BTW.
Please run SegTracker, and enable SegTracker scanning in the involved components (MuForce, MuGA) which would hopefully allow to see where the allocation came from and whose memory it is that is damaged here.

[my_pc_is_amiga]

Thanks for a taking a look.  This is the dump with SegTracker.   

Just to further understand, is it true to assume errors like this could cause memory corruption which the user could see crashes later on but would not know it started here?  I can't tell if error is coming from Pagestream components or the utility 45.2 and so wondering what the severity is if this can't be fixed since Pagestream is not being maintained anymore.

[guest11527]

Thanks for a taking a look.  This is the dump with SegTracker.   

Just to further understand, is it true to assume errors like this could cause memory corruption which the user could see crashes later on but would not know it started here?  I can't tell if error is coming from Pagestream components or the utility 45.2 and so wondering what the severity is if this can't be fixed since Pagestream is not being maintained anymore.

At the point the corrupted memory was picked up, no Os components were involved. The utility.library you see in the stack traceback does not allocate memory itself. Unfortunately, at the time the corruption appears, it is too late to say which code caused the corruption, except that it was likely allococated by pagestream and one of its components. This points into the direction of pagestream, but one cannot really say.

The best you can do is to find a way to make it reproducable.

[my_pc_is_amiga]

On this A4000T / 040, when I load the same large files, it is always reproducible.  I can try more files or maybe an A3000  / 030 machine.

[guest11527]

On this A4000T / 040, when I load the same large files, it is always reproducible.  I can try more files or maybe an A3000  / 030 machine.

That is not quite what I meant. I mean "without pagestream".

[my_pc_is_amiga]

Thanks -- yes will continue to take a look out if see anything similar.   I have recently been putting back my phase5 060/ppc card and now when I do the same thing, I'm not getting any MuGa hit.

As of now I pulled all fast memory except for the PPC card memory.   

On this A4000T / 040, when I load the same large files, it is always reproducible.  I can try more files or maybe an A3000  / 030 machine.

That is not quite what I meant. I mean "without pagestream".

[my_pc_is_amiga]

A few other hits I got in Pagestream and also FinalWriter97 (these don't look like the previous issue).

1) For Pagestream, this happened upon multiple closes of documents and loading of documents.
2) For FW97, I was seeing this after trying to close a window with a large document where I had enabled the pictures (objects) to be loaded.