On Mon, 12 Nov 2012, Gerd Hoffmann wrote:
On 11/10/12 00:45, Marek Vasut wrote:
Dear Gerd Hoffmann,
On 11/09/12 10:50, Peter Maydell wrote:
On 9 November 2012 10:42, Anthony Liguori wrote:
While the abstract discussion is fun, it never hurts to be defensive. I
agree the root cause is vmwar
Hi,
>> I'd go for clipping rather than asserting too (no crash) in all layers
>> as a defensive approach (console.c/vnc.c).
>
> Won't that be an unnecessary slowdown?
Thats why I tend to prefer assert for additional sanity checks. They
help finding bugs, but can optionally be compiled out.
B
On 11/10/12 00:45, Marek Vasut wrote:
> Dear Gerd Hoffmann,
>
>> On 11/09/12 10:50, Peter Maydell wrote:
>>> On 9 November 2012 10:42, Anthony Liguori wrote:
While the abstract discussion is fun, it never hurts to be defensive. I
agree the root cause is vmware-vga but checking in vnc d
Dear Gerhard Wiesinger,
> On 10.11.2012 00:52, Peter Maydell wrote:
> > On 10 November 2012 00:45, Marek Vasut wrote:
> >> Gerd Hoffmann wrote:
> >>> Question is just whenever we'll go silently fixup stuff in console.c or
> >>> use assert()s to enforce callers getting this correct. I'd tend to u
On Fri, Nov 9, 2012 at 7:13 AM, Gerhard Wiesinger wrote:
> On 08.11.2012 22:07, Gerd Hoffmann wrote:
>>
>>Hi,
>>
>>> I think this is fixing this at the wrong level. Either we
>>> should require that drivers (in this case vmware_vga.c)
>>> must not call dpy_gfx_update() with out of range values
On 10.11.2012 00:52, Peter Maydell wrote:
On 10 November 2012 00:45, Marek Vasut wrote:
Gerd Hoffmann wrote:
Question is just whenever we'll go silently fixup stuff in console.c or
use assert()s to enforce callers getting this correct. I'd tend to use
assert() as vmware-vga passing bogous stu
On 10 November 2012 00:45, Marek Vasut wrote:
> Gerd Hoffmann wrote:
>> Question is just whenever we'll go silently fixup stuff in console.c or
>> use assert()s to enforce callers getting this correct. I'd tend to use
>> assert() as vmware-vga passing bogous stuff there IMHO indicates there
>> is
Dear Gerd Hoffmann,
> On 11/09/12 10:50, Peter Maydell wrote:
> > On 9 November 2012 10:42, Anthony Liguori wrote:
> >> While the abstract discussion is fun, it never hurts to be defensive. I
> >> agree the root cause is vmware-vga but checking in vnc doesn't hurt.
> >
> > Defensive programming
On 11/09/12 10:50, Peter Maydell wrote:
> On 9 November 2012 10:42, Anthony Liguori wrote:
>> While the abstract discussion is fun, it never hurts to be defensive. I
>> agree the root cause is vmware-vga but checking in vnc doesn't hurt.
>
> Defensive programming would suggest doing the clipping
On 9 November 2012 10:42, Anthony Liguori wrote:
> While the abstract discussion is fun, it never hurts to be defensive. I
> agree the root cause is vmware-vga but checking in vnc doesn't hurt.
Defensive programming would suggest doing the clipping in the
console.c layer. That sounds a reasonabl
On 09.11.2012 13:00, Michael Tokarev wrote:
> On 09.11.2012 03:55, BALATON Zoltan wrote:
>> On Thu, 8 Nov 2012, Gerd Hoffmann wrote:
I think this is fixing this at the wrong level. Either we
should require that drivers (in this case vmware_vga.c)
must not call dpy_gfx_update() with o
Peter Maydell writes:
> On 9 November 2012 08:13, Gerhard Wiesinger wrote:
>> (think of situations where bits might not be accurate due to CPU bugs or
>> even QEMU/KVM in aerospace where
>> bits fall to other states due to high energy cosmic ray).
>
> If any aeroplane manufacturer is using QEMU
On 09.11.2012 03:55, BALATON Zoltan wrote:
> On Thu, 8 Nov 2012, Gerd Hoffmann wrote:
>>> I think this is fixing this at the wrong level. Either we
>>> should require that drivers (in this case vmware_vga.c)
>>> must not call dpy_gfx_update() with out of range values,
>>> or we should do the clippi
On 9 November 2012 08:13, Gerhard Wiesinger wrote:
> (think of situations where bits might not be accurate due to CPU bugs or
> even QEMU/KVM in aerospace where
> bits fall to other states due to high energy cosmic ray).
If any aeroplane manufacturer is using QEMU for some safety critical
purpose
On 08.11.2012 22:07, Gerd Hoffmann wrote:
Hi,
I think this is fixing this at the wrong level. Either we
should require that drivers (in this case vmware_vga.c)
must not call dpy_gfx_update() with out of range values,
or we should do the clipping in the console.c layer, but
I don't think requ
On Thu, 8 Nov 2012, Gerd Hoffmann wrote:
I think this is fixing this at the wrong level. Either we
should require that drivers (in this case vmware_vga.c)
must not call dpy_gfx_update() with out of range values,
or we should do the clipping in the console.c layer, but
I don't think requiring ever
Hi,
> I think this is fixing this at the wrong level. Either we
> should require that drivers (in this case vmware_vga.c)
> must not call dpy_gfx_update() with out of range values,
> or we should do the clipping in the console.c layer, but
> I don't think requiring every UI backend to clip is th
On 1 November 2012 21:06, Gerhard Wiesinger wrote:
> Fix crash with VNC under NT 4.0 and VMWare VGA and window which is outside
> of the visible area.
>
> Backtrace:
> #0 set_bit (addr=, nr=-3) at ./bitops.h:122
> #1 vnc_dpy_update (ds=, x=-48, y=145, w=57, h=161) at
> ui/vnc.c:452
> #2 0x7
Yet another ping.
Ciao,
Gerhard
On 04.11.2012 11:28, Gerhard Wiesinger wrote:
Ping?
On 01.11.2012 21:06, Gerhard Wiesinger wrote:
Fix crash with VNC under NT 4.0 and VMWare VGA and window which is
outside of the visible area.
Backtrace:
#0 set_bit (addr=, nr=-3) at ./bitops.h:122
#1 vnc_d
Ping?
On 01.11.2012 21:06, Gerhard Wiesinger wrote:
Fix crash with VNC under NT 4.0 and VMWare VGA and window which is
outside of the visible area.
Backtrace:
#0 set_bit (addr=, nr=-3) at ./bitops.h:122
#1 vnc_dpy_update (ds=, x=-48, y=145, w=57, h=161) at
ui/vnc.c:452
#2 0x7f1ce057e2e
Fix crash with VNC under NT 4.0 and VMWare VGA and window which is outside of
the visible area.
Backtrace:
#0 set_bit (addr=, nr=-3) at ./bitops.h:122
#1 vnc_dpy_update (ds=, x=-48, y=145, w=57, h=161) at
ui/vnc.c:452
#2 0x7f1ce057e2ec in dpy_update (s=0x7f1ce1c8c880, h=16, w=66, y=145,
21 matches
Mail list logo
