[quote user="idw"]
[quote user="David Obdrzalek"]But I have run out of ideas how to trace it further on. Any clue what to do now? [/quote]
David Harris uses a customized version of the TER library, and he's working on IMAP (among other stuff) ever since 4.70 was released (or even earlier). WINE issues are, of course, to be handled by the WINE authors, they don't even want us to work around any such issues even if possible (I once discussed a IERenderer issue with them). I would suggest to contact David Harris directly (see the History of Pegasus Mail in its help file).
[/quote]
The strangest thing is that the same data makes Pegasus crash for IMAP-homed email and no crash for an email stored locally. So it crashes only in certain conditions. That sounds like something in relation to networking or temporary file storage and I can easily imagine some kind of race conditions being in charge of the problem (e.g. manipulation with a file sooner than the data is flushed so it is not really available yet although the write call returned - or so). After all, that does not look like a bug in Wine, more likely it is either a problem in the Pegasus application (or its 3rd party libraries) maybe also in combination with something not yet implemented in Wine.
The crash behaviour tells TER dereferences a null pointer. I believe
that pointer came somehow from a system call, which was handled by Wine
and 0 was returned (*) while genuine Windows
return a valid pointer in that situation. Obviously, TER developers did
not test data returning from system calls which is the precise cause of
the crash. This was clearly their problem, but it has changed in later version (TER v 2.3 in my case). It does not crash any more but at the same time new TER produces unreadable html output. That is another problem and this new issue looks like a consequence of an unimplemented feature in Wine (at least new TER calls GetCharacterPlacementW
asking for caret positions which is unimplemented and Wine knows it, while the old version did not). That can be solved in Wine, either waiting enough for the developers to implement it by time, or, as Wine source code is available, someone more fluent in Windows
internals might be able to implement it and propose to include it to
Wine as anyone else. But I don't know at first what is missing and at
second how that should be implemented.
(*) The reason Wine returned 0 for something might be either something not yet implemented, or a proper behaviour in case of something like the race conditions I mentioned earlier.
I'll try to contact David, thanks for idea. I would be honoured if I could meaningfully contribute to v5 :-)
[quote user="idw"]<p>[quote user="David Obdrzalek"]But I have run out of ideas how to trace it further on. Any clue what to do now? [/quote]</p><p>David Harris uses a customized version of the TER library, and he's working on IMAP (among other stuff) ever since 4.70 was released (or even earlier). WINE issues are, of course, to be handled by the WINE authors, they don't even want us to work around any such issues even if possible (I once discussed a IERenderer issue with them). I would suggest to contact David Harris directly (see the <i>History of Pegasus Mail</i> in its help file).
</p><p>[/quote]</p><p>The strangest thing is that the same data makes Pegasus crash for IMAP-homed email and no crash for an email stored locally. So it crashes only in certain conditions. That sounds like something in relation to networking or temporary file storage and I can easily imagine some kind of race conditions being in charge of the problem (e.g. manipulation with a file sooner than the data is flushed so it is not really available yet although the write call returned - or so). After all, that does not look like a bug in Wine, more likely it is either a problem in the Pegasus application (or its 3rd party libraries) maybe also in combination with something not yet implemented in Wine.
</p><p>The crash behaviour tells TER dereferences a null pointer. I believe
that pointer came somehow from a system call, which was handled by Wine
and 0 was returned (*) while genuine Windows
return a valid pointer in that situation. Obviously, TER developers did
not test data returning from system calls which is the precise cause of
the crash. This was clearly their problem, but it has changed in later version (TER v 2.3 in my case). It does not crash any more but at the same time new TER produces <span class="pl-c">unreadable html output</span>. That is another problem and this new issue looks like a consequence of an unimplemented feature in Wine (at least new TER calls <span class="pl-c">GetCharacterPlacementW
asking for caret positions which is unimplemented and Wine knows it, while the old version did not). That can </span>be solved <span class="pl-c"></span>in Wine, either waiting enough for the developers to implement it by time, or, as Wine source code is available,&nbsp; someone more fluent in Windows
internals might be able to implement it and propose to include it to
Wine as anyone else. But I don't know at first what is missing and at
second how that should be implemented. </p><p>(*) The reason Wine returned 0 for something might be either something not yet implemented, or a proper behaviour in case of something like the race conditions I mentioned earlier.
</p><p>&nbsp;I'll try to contact David, thanks for idea. I would be honoured if I could meaningfully contribute to v5 :-)
</p>