[Freeciv-Dev] (PR#40853) Freeciv crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40853 Apple Bug report follow: --- Process: Freeciv [24839] Path:/Applications/Freeciv.app/Contents/MacOS/Freeciv Identifier: freeciv.org.Freeciv-2.1.6 Version: Freeciv-2.1.6 version 0.2 (0.2) Code Type: X86 (Native) Parent Process: launchd [75] Interval Since Last Report: 267827 sec Crashes Since Last Report: 3 Per-App Interval Since Last Report: 8200 sec Per-App Crashes Since Last Report: 2 Date/Time: 2009-07-09 00:21:03.956 +0200 OS Version: Mac OS X 10.5.7 (9J61) Report Version: 6 Anonymous UUID: 5E86B6D4-C2CC-448E-81AF-38EFD2D738D0 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0004 Crashed Thread: 0 Thread 0 Crashed: 0 freeciv.org.Freeciv-2.1.6 0xc339 city_buy_production + 9 1 freeciv.org.Freeciv-2.1.6 0x00021c53 ok_buy_prod_city_dlg_callback + 51 2 freeciv.org.Freeciv-2.1.6 0x0007c5f6 widget_pressed_action + 150 3 freeciv.org.Freeciv-2.1.6 0x00047b11 main_mouse_button_down_handler + 65 4 freeciv.org.Freeciv-2.1.6 0x000487ae gui_event_loop + 702 5 freeciv.org.Freeciv-2.1.6 0x00048edf ui_main + 671 6 freeciv.org.Freeciv-2.1.6 0xf395 SDL_main + 773 7 freeciv.org.Freeciv-2.1.6 0x2ae2 -[SDLMain applicationDidFinishLaunching:] + 66 8 com.apple.Foundation0x9378543a _nsnote_callback + 106 9 com.apple.CoreFoundation0x955b564a __CFXNotificationPost + 362 10 com.apple.CoreFoundation0x955b5923 _CFXNotificationPostNotification + 179 11 com.apple.Foundation0x93782690 -[NSNotificationCenter postNotificationName:object:userInfo:] + 128 12 com.apple.Foundation0x9378bee8 -[NSNotificationCenter postNotificationName:object:] + 56 13 com.apple.AppKit0x9067642a -[NSApplication _postDidFinishNotification] + 125 14 com.apple.AppKit0x90676339 -[NSApplication _sendFinishLaunchingNotification] + 77 15 com.apple.AppKit0x905efe53 -[NSApplication(NSAppleEventHandling) _handleAEOpen:] + 284 16 com.apple.AppKit0x905ef64c -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 98 17 com.apple.Foundation0x937f -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 655 18 com.apple.Foundation0x937aa7bf _NSAppleEventManagerGenericHandler + 223 19 com.apple.AE0x956a8648 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 144 20 com.apple.AE0x956a857e dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 44 21 com.apple.AE0x956a8425 aeProcessAppleEvent + 177 22 com.apple.HIToolbox 0x95ace961 AEProcessAppleEvent + 38 23 com.apple.AppKit0x905ecf21 _DPSNextEvent + 1189 24 com.apple.AppKit0x905ec5c0 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 25 com.apple.AppKit0x905e55fb -[NSApplication run] + 795 26 freeciv.org.Freeciv-2.1.6 0x31cc main + 1436 27 freeciv.org.Freeciv-2.1.6 0x28a6 start + 54 Thread 1: 0 libSystem.B.dylib 0x953fa286 mach_msg_trap + 10 1 libSystem.B.dylib 0x95401a7c mach_msg + 72 2 com.apple.CoreFoundation0x955d404e CFRunLoopRunSpecific + 1790 3 com.apple.CoreFoundation0x955d4c78 CFRunLoopRunInMode + 88 4 com.apple.audio.CoreAudio 0x9305b5f8 HALRunLoop::OwnThread(void*) + 160 5 com.apple.audio.CoreAudio 0x9305b480 CAPThread::Entry(CAPThread*) + 96 6 libSystem.B.dylib 0x9542b155 _pthread_start + 321 7 libSystem.B.dylib 0x9542b012 thread_start + 34 Thread 2: 0 libSystem.B.dylib 0x953fa2e6 semaphore_timedwait_signal_trap + 10 1 libSystem.B.dylib 0x9542c2af _pthread_cond_wait + 1244 2 libSystem.B.dylib 0x9542db33 pthread_cond_timedwait_relative_np + 47 3 com.apple.audio.CoreAudio 0x9306abdf CAGuard::WaitFor(unsigned long long) + 213 4 com.apple.audio.CoreAudio 0x9306c79a CAGuard::WaitUntil(unsigned long long) + 70 5 com.apple.audio.CoreAudio 0x9306af3f HP_IOThread::WorkLoop() + 759 6 com.apple.audio.CoreAudio 0x9306ac43 HP_IOThread::ThreadEntry(HP_IOThread*) + 17 7 com.apple.audio.CoreAudio 0x9305b480 CAPThread::Entry(CAPThread*) + 96 8 libSystem.B.dylib 0x9542b155 _pthread_start + 321 9 libSystem.B.dylib 0x9542b012 thread_start + 34 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x0004 ebx: 0x0003 ecx: 0xa0399a24 edx: 0x29b07710 edi: 0x02e0102a esi: 0x29b07710
Re: [Freeciv-Dev] Patch tracker
note to myself: remember to send emails also to the mailing list ... Am Wednesday 08 July 2009 20:50:19 schrieben Sie: 2009/7/8 Matthias Pfafferodt matthias.pfaffer...@mapfa.de: Patch-for-bug vs. patch-for-new feature might seem clear to those involved for a time, so it'd probably would give similar results to simply set up tags/keywords that can be assigned by the maintainers to sort the two types for later searches. (Assuming that, like on bugzilla, it's possible to create/assign arbitrary tags.) You are right. At the moment there is one lonely patch waiting in the patches section. I don't know if anybody found the new nation. First you were for using both trackers, but then you agreed on some points of John's mail. Could you clarify which way you would vote at the moment. Sorry if it was not clear. I'm for the use of two different tracker (bugs / patches). But I see John's point that it will create confusion. At my first look on the new bug tracker at gna I also found it strange to find 'bugs' as well as 'patches' and interpreted it as said in my first mail: I would like to see the split bugs patches into two trackers, there bugs includes crashes / errors (+ the patches to correct them) and patches contains new features to freeciv. This way it would also be easier to check if a bug was reported before. After nothing was posted in the section 'patches' I started to use 'bug' for this. A clear text stating that should be reported into which tracker on top of the corresponding pages would be helpful. Matthias Until we have agreed on something, I continue using current practice of posting bug reports, bugfixes and feature patches all to the same tracker. - ML -- Matthias Pfafferodt - http://www.mapfa.de Matthias.Pfafferodt at mapfa.de ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13867] [patch 01/07] get game settings via wrapper functions
Follow-up Comment #3, bug #13867 (project freeciv):
the idea was to switch from a translation after the
wrapper function, i.e.
_(setting_short_help(pset))
to a structure which does the translation within the
wrapper functions, i.e.
const char *setting_short_help(const struct setting *pset)
{
return _(pset-short_help);
}
but this is not (easily) possible as both - the
untranslated as well as the translated - text
is needed.
___
Reply to this item at:
http://gna.org/bugs/?13867
___
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 #13867] [patch 01/07] get game settings via wrapper functions
Follow-up Comment #4, bug #13867 (project freeciv): Ah, oops - my apologies for the noise. I really should have read the patch before sounding off (since I clearly misunderstood the translation tags as being used for static text rather than calculated text). :-p [Still... it's unfortunate that Gna doesn't attach patches to the mailed copy of the ticket like was the case with bugs filed using RT.] ___ Reply to this item at: http://gna.org/bugs/?13867 ___ 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] Supporting multiple clients
Pepeto is #13879: I'm sorry to remake an old discussion, but do we still continue to maintain all this ancestral clients that nobody didn't update for a long time? I think a complicate project like Freeciv would concentrate into one only good client instead of having x incomplete clients. I don't remember such discussion from the past. Do you have some pointers for me? Keeping clients in a compiling state is not thta much work, typically just search and replace. At least they exist if somebody steps up and starts actie development on some of them, like cproc did with 2.1 SDL client. Developers and hardcore players usually prefer GTK client for its feature completeness.SDL client has large user base among average players for its much better look. IIRC some old versions of Windows cannot use gtk or sdl client, only native client. There might be other portability issues in providing any one client to some platforms. Support for multiple clients has served us well in the past. That allowed us to develop gtk client and later gtk2 client so that they were eventually made default client. Had we decided that we will maintain only the best client of the time, we would still be using xaw client. All that said, we could consider level of maintenance for each client. FTWL has been inactive project for a long time. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Patch tracker
2009/7/8 Daniel Markstedt markst...@gmail.com: How about this for the definitions of bug and patch: * A patch is an issue for which you have prepared a fix or is planning to prepare a fix yourself. Typically used by regular contributors. * A bug is an issue for which you do not have a fix and wish for someone else to find one. Typically used by users. No, I think this is worse than obvious bug/feature division. Bug report should be always in bug tracker (and searchable there) and not depend on if I will have time to fix it myself or not. Votes seems to be 2-2 among all developers, and 1-1 among Maintainers. But as this is not so big deal for me, okay, let's use two trackers (assuming nobody else weights in at the last moment). - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13857] [Patch] Debian package building
Update of bug #13857 (project freeciv): Category:None = bootstrap Status:None = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13857 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
