[texworks] mouse-wheel / slider cause TeXworks inmediate crash, issue broadens

[Paul A Norman]

P.S.

Thinking about it I realised that for other reasons since having my
day of 14 crashes, I had reduced my Tw Editor/Preferences font-size.
I am thinking this stopped the wrapped line width causing any
problems.

So a small temporary work around/or partial help may be to leave wrap
line  on, but reduce your Editor font-size to 10pt, this is visually
workable for me using the font "Liberation Mono".

Paul

On 27 January 2011 16:52, Paul A Norman <paul.a.norman at gmail.com> wrote:
> Dear Stefan,
>
> On the 25th January according to my MS Application Events log, I had
> 14 occurrences of this problem in a row, over an eight hour twenty
> minute period. The system log over this time appears to show no
> unusual events.
>
> Today after some four hours of very similar  Tw usage - so far no
> crashes at all - go ask.
>
> One additional thing I have noticed and didn't think to comment on
> originally, with this problem on Xp, sometimes Qt is causing Tw to
> crash instantly with no User error message shown, nor User  error
> reporting cycle. I'm not sure how it it getting "under the radar" like
> that - possible the MS error number 1000 is just ignored as
> untraceable.
>
> Or could this suggest that Qt is protecting User's system from a
> massive overload of some sort.  An unstoppable cycle - or an
> unbreakable loop of some sort?
>
> When following through the MS Application Events log - MS support says:
>
> "Currently there are no Microsoft Knowledge Base articles available
> for this specific error or event message. "
>
> The Application Events log ...
>
> Event Type:     Error
> Event Source:   Application Error
> Event Category: None
> Event ID:       1000
> Date:           25/01/2011
> Time:           6:18:21 p.m.
> User:           N/A
> Computer:       HENRY3
> Description:
> Faulting application texworks.exe, version 0.3.0.728, faulting module
> texworks.exe, version 0.3.0.728, fault address 0x00fb0adb.
>
> Data:
> 0000: 41 70 70 6c 69 63 61 74   Applicat
> 0008: 69 6f 6e 20 46 61 69 6c   ion Fail
> 0010: 75 72 65 20 20 74 65 78   ure  tex
> 0018: 77 6f 72 6b 73 2e 65 78   works.ex
> 0020: 65 20 30 2e 33 2e 30 2e   e 0.3.0.
> 0028: 37 32 38 20 69 6e 20 74   728 in t
> 0030: 65 78 77 6f 72 6b 73 2e   exworks.
> 0038: 65 78 65 20 30 2e 33 2e   exe 0.3.
> 0040: 30 2e 37 32 38 20 61 74   0.728 at
> 0048: 20 6f 66 66 73 65 74 20    offset
> 0050: 30 30 66 62 30 61 64 62   00fb0adb
> 0058: 0d 0a                     ..
>
> Paul
>
> On 26 January 2011 08:39, Stefan Löffler <st.loeffler at gmail.com> wrote:
>> Hi,
>>
>> On 2011-01-25 06:32, Paul A Norman wrote:
>>> This seems to have broadened, or more is surfacing.
>>
>> My guess is the latter... especially since nothing has changed in the
>> builds, recently.
>>
>>> In the debugger the crash can happen when the debugger adds error
>>> lines itself as you click the  green Debugger arrow.
>>
>> This sounds reasonable, as the problem seems to be connected in some way
>> to the line highlighting code (which I think is what is done in the
>> debugger as well).
>>
>>> Also something strange, sometimes when material has been copied to the
>>> clipboard in Tw, if it crashes due to this stuff, the material is no
>>> longer on the clipboard.
>>
>> Yes, this is not entirely inexplicable. If the data is managed by Tw
>> rather than the operating system, the data is naturally lost when Tw
>> crashes. I am a bit surprised that this applies to simple plain text
>> data, but who knows how Qt handles stuff internally.
>>
>>> It seems like a Qt framework issue?
>>
>> Indeed, I think so too. I've tried to get some help on the dev forums
>> (http://developer.qt.nokia.com/forums/viewthread/3176/), but to no avail
>> so far... :(
>>
>>> Do we need to retreat behind 4.7.1 for now?
>>
>> This would be an option, albeit not an ideal one. E.g., Ubuntu 10.10
>> ships with Qt 4.7.0, and avoiding that would be quite difficult. The
>> same thing will probably apply to 11.04, unless there is a new Qt
>> release soon (which I seriously doubt). Similarly, for the Windows
>> builds, I use a system that comes with 4.7.1 right now... All in all
>> this is a big mess.
>>
>> -Stefan
>>
>