[texworks] mouse-wheel / slider cause TeXworks inmediate crash, issue broadens
Paul A Norman
paul.a.norman at gmail.com
Fri Jan 28 22:11:29 CET 2011
Another thing I've noticed is that when I open a Tw document, and
particularly if I last closed the document in a larger sized window
than 'normal', Tw is taking a lot longer to fully open and give the
document t to me in an editable state than it used to.
On 27 January 2011 17:02, Paul A Norman <paul.a.norman at gmail.com> wrote:
> 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
> 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".
> 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
>> 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
>> Faulting application texworks.exe, version 0.3.0.728, faulting module
>> texworks.exe, version 0.3.0.728, fault address 0x00fb0adb.
>> 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 ..
>> On 26 January 2011 08:39, Stefan Löffler <st.loeffler at gmail.com> wrote:
>>> 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.
More information about the texworks