[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Update of bug #15347 (project freeciv): Status: In Progress = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #20, bug #15347 (project freeciv): Christian, if you won't have time to commit this before the release, I'm happy to do it. I will do in the next couple of days if no-one gets there first. ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Update of bug #15347 (project freeciv): Planned Release: = 2.2.3 ___ Follow-up Comment #19: Testing on S2_2 with your patch, all seems fine now on my machine. It even seems to have cleared up a minor pixel dust issue I had noticed before when scrolling around. I think we should try to get this second half of the fix into 2.2.3 (which is planned to be tagged on Sunday 12th). ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Update of bug #15347 (project freeciv): Status: Fixed = In Progress Open/Closed: Closed = Open ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #17, bug #15347 (project freeciv): Thanks for doing something about this. Slight problem: on my machine at least, diagonal trade routes come out dark blue (which gets lost in the ocean), whereas horizontal/vertical lines come out cyan (which is I think the intended colour). Looking at putline(), it still uses the homegrown routines for the special cases, which explains the difference. I assume there's a disagreement about the interpretation of Uint32 color. Really, putline() could just call lineColor() for everything, since lineColor() optimises the special cases already. As for colours, it looks like lineColor() and friends take RGBA as input and call SDL_MapRGBA() themselves, whereas putline() expects SDL_MapRGBA() to have been done for it. Making putline() take RGBA might be the right answer long term, but that (and other changes like using the new gfx routines more extensively) are moderately big projects. A quick but ugly fix might be to invert the mapping in putline(). But at least I can't make it crash any more :) ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Update of bug #15347 (project freeciv): Status: In Progress = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Update of bug #15347 (project freeciv): Assigned to:None = cproc ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #12, bug #15347 (project freeciv): Also reported with some attachments at bug #16522. ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #11, bug #15347 (project freeciv): I've not used the SDL client in a while, so i've no horse in this race. That said, i perfectly agree with the logic that as long as we've loaded a library then we'd be better off using functions from the library rather than rolling our own. There are exceptions, of course, if the available function is insufficient for our needs or it requires lots of work to implement. ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #10, bug #15347 (project freeciv): This bug is languishing, and I haven't had time to look at the latest crash. I've been thinking for a while that it seems a shame to reinvent the wheel for this. It looks like we already incorporate parts of the SDL_gfx library http://www.ferzkopp.net/joomla/software-mainmenu-14/4-ferzkopps-linux-software/19-sdlgfx (client/gui-sdl/SDL_rotozoom.[ch] are from it); and that library also includes line drawing routines. Could we use that instead (either updating our copy, or growing an external dependency on, or both)? Licence is LGPL. ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #9, bug #15347 (project freeciv): I am sorry, I cannot reproduce this crash, even with 1680x1050 resolution. (I also noticed that long diagonal lines generated in stages during scrolling aren't pixel perfect; they look lumpy and occasionally don't join by a pixel or so. Maybe that's expected inaccuracy, I haven't tried to analyse the code at all.) This may the left problem. However, I don't have the required knowledge to investigate more in this direction. Already remembering me Thales theorem was already an exploit to me, as I stopped scientific studies very too early. ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #8, bug #15347 (project freeciv): The attached savegame crashes reliably for me at 1680x1050 resolution. The starting position is towards the top of the map; just right-clicking on the main map to scroll vaguely downwards is enough to reliably crash it for me. (Tried most recently with S2_2 r16958 + your patch.) Interestingly, it doesn't crash reliably in this way at 1280x960 resolution, although it did once throw up an impressively garbled display followed by a crash (I'm afraid I have no record of either). (I also noticed that long diagonal lines generated in stages during scrolling aren't pixel perfect; they look lumpy and occasionally don't join by a pixel or so. Maybe that's expected inaccuracy, I haven't tried to analyse the code at all.) (file #8307) ___ Additional Item Attachment: File name: canadians-T280-Y1810ADm.sav.bz2 Size:48 KB ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #7, bug #15347 (project freeciv): Do you have a savegame I could use to test. With mines, I never get this crash, and I don't want to do blind suppositions. ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Update of bug #15347 (project freeciv): Status:None = In Progress ___ Follow-up Comment #5: Looks a lot better, thanks, but I did get one more segfault (while scrolling downwards). What is this branch? What is your line 906. For me there is really nothing which could cause a crash there: only a comparison between normal integers. I'm also seeing pixel dust appearing when scrolling left -- it looks as though lines drawn to the extreme right of the screen bleed onto the left side by one pixel. I'm seeing this from city labels even with trade route drawing disabled, so this may be a new bug. I think, this is quite linked, but I couldn't remove them. I think, it's linked with the drawing code below the changes. ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #6, bug #15347 (project freeciv): What is this branch? What is your line 906. For me there is really nothing which could cause a crash there: only a comparison between normal integers. Sorry, should have said. This is S2_2 r16896 with your patch. Line 906 is *(Uint32 *) pPixel = color; in put_line(). It's the same if I update to S2_2 r16908 (same line). ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Update of bug #15347 (project freeciv): Status:None = Ready For Test Assigned to:None = pepeto Release: = S2_1, S2_2, trunk Planned Release: = 2.1.12, 2.2.1 ___ Follow-up Comment #3: Algorithm fix attached. (file #8146) ___ Additional Item Attachment: File name: trunk_S2_2_S2_1_sdl_put_line.diff Size:4 KB ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
URL: http://gna.org/bugs/?15347 Summary: Bad drawing and floating point exception with trade route line drawing in SDL client Project: Freeciv Submitted by: jtn Submitted on: Friday 12/02/10 at 23:22 Category: client-sdl Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: GNU/Linux Planned Release: ___ Details: In both S2_1 and S2_2, I'm finding that if I have trade route line drawing enabled, the lines are drawn wrong and the client dies soon after starting, with a floating point exception (or sometimes it dies as soon as a save file is loaded). Turning off trade route line drawing (e.g. by editing the ~/.civclientrc or equivalent), the client seems stable. (I usually use the Gtk client, and noticed this while testing the SDL client. As far as I can tell the SDL client doesn't actually have an option to toggle trade route line drawing, which might be why no-one's noticed this; hence priority Normal. ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #1, bug #15347 (project freeciv):
Here's a backtrace of S2_1 r16811, in a case where it died instantly at
startup.
Attached is a screenshot of a different session, showing bad drawing; that
time it died after a bit of scrolling.
#0 0x004ccc9a in putline (pDest=0x2418930, x0=671, y0=-96, x1=32,
y1=-96, color=65480) at graphics.c:832
No locals.
#1 0x0041d141 in draw_traderoute_line (ptile1=value optimized
out,
ptile2=value optimized out, color=value optimized out)
at mapview_common.c:1161
line_count = 1
i = 1
pcolor = (struct color *) 0x7f42d8cb4460
#2 0x0041d1c5 in draw_traderoutes_for_city (pcity_src=0x3778dd0)
at mapview_common.c:1185
pcity_dest = (const struct city *) 0xfd81
#3 0x0041e13d in update_map_canvas (canvas_x=0, canvas_y=288,
width=640, height=192) at mapview_common.c:1210
gui_x0 = -32
gui_y0 = 480
full = false
tmp = value optimized out
#4 0x0041fe87 in base_set_mapview_origin (gui_x0=-32, gui_y0=192)
at mapview_common.c:521
target = (struct canvas *) 0x2418a40
old_gui_x0 = 0
old_gui_y0 = 0
dx = -32
dy = 192
width = 640
height = value optimized out
common_x0 = value optimized out
common_x1 = 608
common_y0 = 192
common_y1 = 480
update_x0 = -32
update_x1 = 0
update_y0 = 288
update_y1 = 192
#5 0x00420089 in set_mapview_origin (gui_x0=-32, gui_y0=192)
at mapview_common.c:625
xmin = -5072
xmax = 8768
ymin = -240
ymax = 6840
xsize = 640
ysize = 480
anim_timer = (struct timer *) 0x0
total_frames = 0.01
total_time = 0.0001
#6 0x0042016b in center_tile_mapcanvas (ptile=value optimized
out)
at mapview_common.c:799
gui_x = -32
gui_y = 32
first = false
#7 0x0040bd9e in center_on_something () at climisc.c:417
pcity = value optimized out
__PRETTY_FUNCTION__ = center_on_something
#8 0x00424bc2 in handle_game_state (value=3) at packhand.c:394
No locals.
#9 0x00427ae4 in client_handle_packet (type=4294966657,
packet=0xffa0) at packhand_gen.c:58
No locals.
#10 0x0040949d in client_packet_input (packet=value optimized out,
type=12) at civclient.c:456
No locals.
#11 0x0040d151 in input_from_server (fd=value optimized out)
at clinet.c:387
result = true
packet = (void *) 0xfd81
type = PACKET_GAME_STATE
__PRETTY_FUNCTION__ = input_from_server
#12 0x004ceed0 in gui_event_loop (pData=0x0, loop_action=0,
key_down_handler=0x4ce4c0 main_key_down_handler,
key_up_handler=0x4ce070 main_key_up_handler,
mouse_button_down_handler=0x4ce400 main_mouse_button_down_handler,
mouse_button_up_handler=0x4ce3a0 main_mouse_button_up_handler,
mouse_motion_handler=0x4ce0a0 main_mouse_motion_handler)
at gui_main.c:724
ID = 0
t_current = 12417
t_last_unit_anim = 12417
t_last_map_scrolling = 12417
real_timer_next_call = 13229
tv = {tv_sec = 0, tv_usec = }
civfdset = {fds_bits = {2048, 0 repeats 15 times}}
result = 1
schot_nr = 0
schot = '\0' repeats 31 times
#13 0x004cf2d2 in ui_main (argc=1, argv=value optimized out)
at gui_main.c:1005
__Net_User_Event = {type = 24 '\030', active = {type = 24 '\030',
gain = 88 'X', state = 81 'Q'}, key = {type = 24 '\030', which = 88 'X',
state = 81 'Q', keysym = {scancode = 1 '\001', sym = SDLK_UNKNOWN,
mod = KMOD_NONE, unicode = 0}}, motion = {type = 24 '\030',
which = 88 'X', state = 81 'Q', x = 1, y = 0, xrel = 0, yrel = 0},
button = {type = 24 '\030', which = 88 'X', button = 81 'Q', state = 0
'\0',
x = 1, y = 0}, jaxis = {type = 24 '\030', which = 88 'X', axis = 81 'Q',
value = 1}, jball = {type = 24 '\030', which = 88 'X', ball = 81 'Q',
xrel = 1, yrel = 0}, jhat = {type = 24 '\030', which = 88 'X',
hat = 81 'Q', value = 0 '\0'}, jbutton = {type = 24 '\030',
which = 88 'X', button = 81 'Q', state = 0 '\0'}, resize = {
type = 24 '\030', w = 1, h = 0}, expose = {type = 24 '\030'}, quit = {
type = 24 '\030'}, user = {type = 24 '\030', code = 1, data1 = 0x0,
data2 = 0x0}, syswm = {type = 24 '\030', msg = 0x0}}
__GGZ_User_Event = {type = 24 '\030', active = {type = 24 '\030',
gain = 0 '\0', state = 0 '\0'}, key = {type = 24 '\030', which = 0 '\0',
state = 0 '\0', keysym = {scancode = 2 '\002', sym = SDLK_UNKNOWN,
mod = KMOD_NONE, unicode = 0}}, motion = {type = 24 '\030',
which = 0 '\0', state = 0 '\0', x = 2, y = 0, xrel = 0, yrel = 0},
button = {type = 24 '\030', which = 0 '\0', button = 0 '\0', state = 0
'\0',
x = 2, y = 0}, jaxis = {type = 24 '\030', which =
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Additional Item Attachment, bug #15347 (project freeciv): File name: S2_1_initscr_bad_tr.pngSize:890 KB ___ Reply to this item at: http://gna.org/bugs/?15347 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15347] Bad drawing and floating point exception with trade route line drawing in SDL client
Follow-up Comment #2, bug #15347 (project freeciv):
...and here's a backtrace from S2_2 r16811.
Also a screenshot (again, a different session), in which I was able to scroll
rightwards a few times (it crashed soon after).
#0 0x0048ae3a in putline (pDest=0x1cd5cc0, x0=1343, y0=-120,
x1=-368,
y1=-120, color=65407) at graphics.c:832
No locals.
#1 0x0043ffc9 in draw_trade_route_line (ptile1=value optimized
out,
ptile2=value optimized out, color=value optimized out)
at mapview_common.c:1169
line_count = 1
i = 1
pcolor = (struct color *) 0x1c92a10
#2 0x0044008c in draw_trade_routes_for_city (pcity_src=0x4ed75d0)
at mapview_common.c:1193
pcity_dest = value optimized out
#3 0x004412be in update_map_canvas (canvas_x=0, canvas_y=950,
width=1280, height=10) at mapview_common.c:1217
gui_x0 = 1568
gui_y0 = 2438
full = false
tmp = value optimized out
#4 0x00442f87 in base_set_mapview_origin (gui_x0=1568, gui_y0=1488)
at mapview_common.c:527
target = (struct canvas *) 0x1cd5d20
old_gui_x0 = 1593
old_gui_y0 = 1478
dx = -25
dy = 10
width = 1280
height = value optimized out
common_x0 = value optimized out
common_x1 = 1255
common_y0 = 1488
common_y1 = 2438
update_x0 = 1568
update_x1 = 1593
update_y0 = 950
update_y1 = 10
#5 0x0044311e in set_mapview_origin (gui_x0=1568, gui_y0=1488)
at mapview_common.c:611
diff_x = -384
timing_sec = 0.20001
frames = 7
start_y = value optimized out
diff_y = 144
currtime = 0.21528347523423641
xmin = -2400
xmax = 3632
ymin = 1152
ymax = 2712
xsize = 1280
ysize = 960
anim_timer = (struct timer *) 0x2d98a20
total_frames = 131.67085384457317
total_time = 4.3232117187765562
#6 0x0044326b in center_tile_mapcanvas (ptile=value optimized
out)
at mapview_common.c:805
gui_x = 1568
gui_y = -368
first = false
#7 0x0040b977 in button_up_on_map (button_behavior=0x77ae00)
at mapctrl.c:2233
ptile = value optimized out
pCity = value optimized out
#8 0x004050ab in main_mouse_button_up_handler
(pButtonEvent=0x8081b0,
pData=value optimized out) at gui_main.c:331
No locals.
#9 0x004057f4 in gui_event_loop (pData=0x0, loop_action=0,
key_down_handler=0x405170 main_key_down_handler,
key_up_handler=0x404d20 main_key_up_handler,
mouse_button_down_handler=0x4050b0 main_mouse_button_down_handler,
mouse_button_up_handler=0x405050 main_mouse_button_up_handler,
mouse_motion_handler=0x404d50 main_mouse_motion_handler)
at gui_main.c:680
ID = 0
t_current = value optimized out
t_last_unit_anim = 30569
t_last_map_scrolling = 30599
real_timer_next_call = 30628
tv = {tv_sec = 0, tv_usec = 0}
civfdset = {fds_bits = {0 repeats 16 times}}
result = 0
schot_nr = 0
schot = '\0' repeats 31 times
#10 0x00405f52 in ui_main (argc=1, argv=0x7fff081d64b8)
at gui_main.c:992
__Net_User_Event = {type = 24 '\030', active = {type = 24 '\030',
gain = 0 '\0', state = 0 '\0'}, key = {type = 24 '\030', which = 0 '\0',
state = 0 '\0', keysym = {scancode = 1 '\001', sym = SDLK_UNKNOWN,
mod = KMOD_NONE, unicode = 0}}, motion = {type = 24 '\030',
which = 0 '\0', state = 0 '\0', x = 1, y = 0, xrel = 0, yrel = 0},
button = {type = 24 '\030', which = 0 '\0', button = 0 '\0', state = 0
'\0',
x = 1, y = 0}, jaxis = {type = 24 '\030', which = 0 '\0', axis = 0 '\0',
value = 1}, jball = {type = 24 '\030', which = 0 '\0', ball = 0 '\0',
xrel = 1, yrel = 0}, jhat = {type = 24 '\030', which = 0 '\0',
hat = 0 '\0', value = 0 '\0'}, jbutton = {type = 24 '\030',
which = 0 '\0', button = 0 '\0', state = 0 '\0'}, resize = {
type = 24 '\030', w = 1, h = 0}, expose = {type = 24 '\030'}, quit = {
type = 24 '\030'}, user = {type = 24 '\030', code = 1, data1 = 0x0,
data2 = 0x0}, syswm = {type = 24 '\030', msg = 0x0}}
__GGZ_User_Event = {type = 24 '\030', active = {type = 24 '\030',
gain = 0 '\0', state = 0 '\0'}, key = {type = 24 '\030', which = 0 '\0',
state = 0 '\0', keysym = {scancode = 2 '\002', sym = SDLK_UNKNOWN,
mod = KMOD_NONE, unicode = 0}}, motion = {type = 24 '\030',
which = 0 '\0', state = 0 '\0', x = 2, y = 0, xrel = 0, yrel = 0},
button = {type = 24 '\030', which = 0 '\0', button = 0 '\0', state = 0
'\0',
x = 2, y = 0}, jaxis = {type = 24 '\030', which = 0 '\0', axis = 0 '\0',
value = 2}, jball = {type = 24 '\030', which = 0 '\0', ball = 0 '\0',
xrel = 2, yrel = 0}, jhat = {type = 24 '\030', which = 0 '\0',
hat = 0 '\0', value = 0
