Re: ddraw: allow explicit backbuffer
On Sat, Oct 27, 2007 at 06:18:53PM -0500, EA Durbin wrote:
based on patch by Jaroslav Reznik, this fixes bug 9008 and allows the game
combat pillows to launch
_
Climb to the top of the charts! Play Star Shuffle: the word scramble
challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct
From d6c94c504f555f773c2c90d7fcbd4bf3500fe490 Mon Sep 17 00:00:00 2001
From: EA Durbin [EMAIL PROTECTED]
Date: Sat, 27 Oct 2007 18:16:27 -0500
Subject: ddraw: allow explicit backbuffer, based on a patch by Jaroslav Reznik
---
dlls/ddraw/ddraw.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c
index 7785624..a84fc36 100644
--- a/dlls/ddraw/ddraw.c
+++ b/dlls/ddraw/ddraw.c
@@ -2283,7 +2283,7 @@ IDirectDrawImpl_CreateSurface(IDirectDraw7 *iface,
return DDERR_NOEXCLUSIVEMODE;
}
-if(DDSD-ddsCaps.dwCaps (DDSCAPS_FRONTBUFFER | DDSCAPS_BACKBUFFER)) {
+if(DDSD-ddsCaps.dwCaps (DDSCAPS_FRONTBUFFER || DDSCAPS_BACKBUFFER)) {
This is wrong. You changed a logical OR into a boolean OR and the bitmask will
no
longer work...
Something else needs to be changed, like removing either the DDSCAPS_BACKBUFFER
part or the FRONTBUFFER part of the |.
Ciao, Marcus
Re: ddraw: allow explicit backbuffer
Am Sonntag, 28. Oktober 2007 01:18:53 schrieb EA Durbin: based on patch by Jaroslav Reznik, this fixes bug 9008 and allows the game combat pillows to launch There is a test in the ddraw tests that shows that this is not allowed. This test will break I guess. However, maybe it is a version differece. The test tests IDirectDraw7 I think, maybe the game uses an older version. signature.asc Description: This is a digitally signed message part.
Re: Make test drill, next steps, call for help with Winetest
On Sa, 2007-10-27 at 14:03 +0200, Francois Gouget wrote: Things still on the todo list: * the script also grabs the winetest.exe signature and attempts to verify it. But I don't know where to find the corresponding public key (651FD487) so I don't know if this really works. Paul's homepage: http://www.astro.gla.ac.uk/users/paulm/ $ gpg --list-keys paulm pub 1024D/BF0F03E9 2000-11-07 uid Paul Millar (Physics Astronomy) sub 1024g/1034BACC 2000-11-07 pub 1024D/651FD487 2002-05-11 uid quisquiliae (automatic program for testing WINE) sub 1024g/420F3FE4 2002-05-11 (The email-address was stripped) My script loads the signature and verify the winetest-latest.exe. When gpg failed to verify the binary, a new winetest is available. The new binary is downloaded and checked again. When the check was ok, the winetest-lastest is copied to the destination and qemu is started for every image. To bad, that qemu 0.9.0 crash on ntdll_text.exe exception ... -- By by ... Detlef
Re: Lots of 'make test' failures on Windows
On 27/10/2007, Jakob Eriksson [EMAIL PROTECTED] wrote: Francois Gouget wrote: And I have recently put together a script for running winetest in VMware virtual machines unattended (see my other post). So going forward I will be running it on Windows 98, Windows XP and Windows 2003 nightly. This is s good. test.winehq.org will became several times more useful than before. A consistent track record from the same installations of Windows. I agree. It would be even better if the tests were also run on real machines, as that would catch which test failures are VM related (such as the Direct3D tests). - Reece
Re: tools/widl/typegen.c pointer initialization
On Sun, Oct 28, 2007 at 01:51:34PM +0100, Gerald Pfeifer wrote:
In tools/widl/typegen.c we have the following snippet
static void write_user_tfs(FILE *file, type_t *type, unsigned int *tafsoff)
{
unsigned int start, absoff, flags;
unsigned int align = 0, ualign = 0;
const char *name;
type_t *utype = get_user_type(type, name);
which passes name to get_user_type without initializing it. get_user_type
in return has the following piece of code:
static type_t *get_user_type(const type_t *t, const char **pname)
{
for (;;)
{
type_t *ut = get_attrp(t-attrs, ATTR_WIREMARSHAL);
if (ut)
{
if (pname)
*pname = t-name;
return ut;
}
It is unclear to this reader (and various versions of GCC I tested),
whether we don't really use *name (*pname) uninitialized here. Now
it is possible that through some of the, hmm, tricky logic in these
two functions combined with some environmental guarantees it happens
that we don't, but it seems better to be proactive here.
The logic is as follows: We wouldn't be in write_user_tfs if the
predicate is_user_type wasn't true for that type, which means *pname
(name) will always be initialized since it gets set precisely when
get_user_type returns non-NULL (which is the is_user_type test). I
don't think initializing it to NULL is helpful since it would crash just
the same as if it weren't initialized. name *must* have a valid
(non-NULL) value. This may silence a warning, but it's making the logic
of the code more confusing by setting the variable to a value that
doesn't make any sense in that context. get_user_type is the
initialization.
Better than this would be to put assert(is_user_type(type)); above the
initializations to convince the programmer at least that name will get
initialized correctly in get_user_type. If that doesn't convince the
compiler then I don't think it's worth it to try to placate it since
we're supposed to be wrting code for humans, not computers. Some
projects use a macro like name IF_LINT(= NULL); to quiet warnings
while informing the reader that the initialization is not necessary. I
suppose that's slightly better as well.
I think the real problem is that the code is just not clear enough.
I've been meaning to add asserts. Where asserts are impractical:
comments.
Re: [1/3] comctl32: Do not call parent of tool window for tip text
Hi Alexander, In the process of debugging I also determined that Windows doesn't seem to send this message to parent at all (tested on win98-Qemu, winXP SP2-Qemu and winXP SP1 normal installation). So I'm deleting this second call altogether and a conformance test for this situation will be included in the next patch. Under some circumstances, it must - see bug 9233 (and my patch at url below) http://www.winehq.org/pipermail/wine-patches/2007-August/042660.html http://www.winehq.org/pipermail/wine-cvs/2007-August/035236.html I debugged this through to the point where the parent was definitely retrieving the information (I watched spy logs of the application in question) and I believe reversing this patch will break radmin again... It's a free download, can you please test you havent regressed that application with the patch Jason
Re: ddraw: allow explicit backbuffer
There is a test in the ddraw tests that shows that this is not allowed. This test will break I guess. However, maybe it is a version differece. The test tests IDirectDraw7 I think, maybe the game uses an older version. It looks like DirectX 6.0 and above game (requirement in their web) but this is quite new version. It is very popular in Czech and general rating of quality of Wine for many Czech users :) It's free game, you can download it here http://download.sleepteam.com/bulanci.exe - Czech version called Bulanci. Jaroslav Reznik
Re: [1/3] comctl32: Do not call parent of tool window for tip text
Hi. Thanks for your input. I did download this application, and, yeah, it appears that my patch regresses it. However, I did a bit of debugging of my own and I don't think that the real problem in RAdmin case is not sending the message to the parent, just like it isn't in DCPlusPlus, the real problem seems to be on toolbar's side again. Sending message to parent in tooltip code probably simply works around toolbar's broken behavior. In this case I think I've identified a line in toolbar.c that fails to properly detect empty string causing not appearing tooltips in Radmin. I'll try to submit another patch with this fix shortly. Ann Jason Edmeades wrote: Hi Alexander, In the process of debugging I also determined that Windows doesn't seem to send this message to parent at all (tested on win98-Qemu, winXP SP2-Qemu and winXP SP1 normal installation). So I'm deleting this second call altogether and a conformance test for this situation will be included in the next patch. Under some circumstances, it must - see bug 9233 (and my patch at url below) http://www.winehq.org/pipermail/wine-patches/2007-August/042660.html http://www.winehq.org/pipermail/wine-cvs/2007-August/035236.html I debugged this through to the point where the parent was definitely retrieving the information (I watched spy logs of the application in question) and I believe reversing this patch will break radmin again... It's a free download, can you please test you havent regressed that application with the patch Jason
Pegasus Mail: program closes when sub-program closes
Sent to bugzilla, and to this email addy, as per winehq instructions: http://www.pmail.com/downloads_maine_t.htm Version to look at is 4.41, a free download. This email app does a normal shutdown whenever the editor is closed, e.g., after a new email is sent. This is not normal behaviour. In Windows the app stays open, so that one can continue sending, receiving, reading, writing email, etc. In old versions of wine, this error doesn't happen, (ver. 20050830). The regression error occurs as early as 0.9.20. Based on posts to the wine appdb for this app, it is likely that the regression error ocurred =0.9.14. The editor in Pmail was not written by the developer and maintainer, David Harris, but rather licensed by him. Recent wine code seems to interpret an ordinary call to close the editor as a call to close the program itself. When Pmail starts, a 0 byte file, mailbox.lck is created in the mail box of the user. When the user closes the program normally, this file is deleted. Since the shutdown regression error deletes the lock file, I conclude the call to close the editor is being misinterpreted by wine as a call to shutdown Pmail. Joel Barnett New super maintainer for Pegasus Mail p.s. - I'm new at this, please forgive me if my report is funky. I did check bugzilla and didn't find anything relevant.
Re: [1/3] comctl32: Do not call parent of tool window for tip text
Sending message to parent in tooltip code probably simply works around toolbar's broken behavior. In this case I think I've identified a line in toolbar.c that fails to properly detect empty string causing not appearing tooltips in Radmin. I'll try to submit another patch with this fix shortly. Thanks for checking this out - If your new patch makes tooltips work, I should probably be quiet... But.. I was looking through my notes of when I was working on this bug, looking at SPY++ logs from windows and comparing them with +spy,+message,+msg etc logs from wine. My notes indicated I was seeing the following sequence (I have hwnds or whatever spy logs written down): Tooltip sends toolbar needtextW Sends to base class tbn_GetInfoTipA which didn't return anything Sends tbn_GetInfoTipA to its parent which didn't return anything Tooltip sends baseclass ttn NeedTextA Which forwards to parent as ttn NeedTextA My notes and investigations could be wrong, does this tie up with what you were seing? Jason
Re: [1/3] comctl32: Do not call parent of tool window for tip text
From what I've seen in +tooltips,+toolbar,+msg logs and from running the apps in IDA Pro disassembler, it works like follows: * TOOLTIPS_GetTipText calls TOOLTIPS_GetDispInfoA/W * TOOLTIPS_GetDispInfoA/W sends TTN_GETDISPINFO(=TTN_NEEDTEXT) notification to tool's notify window, which is toolbar's window; tool's id (which is equal to toolbar button's commandid) is passed in wparam * it gets to TOOLBAR_TTGetDispInfo handler now, what I think really should happen in these apps, is TOOLBAR_TTGetDispInfo in its last step should send TTN_GETDISPINFO/TTN_NEEDTEXT to the toolbar's notify window and put button's command id (taken from tooltip tool's id) in wparam. In both DCPlusPlus and RAdmin this returns a correct tip text. Now the problem is, because of bugs in TOOLBAR_TTGetDispInfo, it wasn't sending exactly such message. First, because it wasn't putting any meaningful value in wparam (fixed by my patch 3/3), second (what I wasn't aware of before you told me of RAdmin) in ANSI version it wasn't even getting to that last step (sending TTN_GETDISPINFO/TTN_NEEDTEXT) - fixed by 4/3. So then it was returning to TOOLTIPS_GetDispInfoA/W which tried to send TTN_GETDISPINFO to the parent with tool's id in wparam - note that it's essentially the same thing toolbar will do if bugs in it are fixed. So in RAdmin case tooltips control was sort of successfully compensating for bugs in toolbar's handler. But, in DCPlusPlus case , only after the application already got a wrong TTN_GETDISPINFO notification (with wparam = 0) from toobar's handler. About that message sequence you describe, can you clarify if it's recorded on Native or Wine? It looks right for Wine (without my patches applied), but if that happened on native, then there may be a problem, because I don't know how that could be happening. Conformance test I've written, for example, indicates that parent window of tool's notify window doesn't get called by tooltip. Ann Jason Edmeades wrote: Sending message to parent in tooltip code probably simply works around toolbar's broken behavior. In this case I think I've identified a line in toolbar.c that fails to properly detect empty string causing not appearing tooltips in Radmin. I'll try to submit another patch with this fix shortly. Thanks for checking this out - If your new patch makes tooltips work, I should probably be quiet... But.. I was looking through my notes of when I was working on this bug, looking at SPY++ logs from windows and comparing them with +spy,+message,+msg etc logs from wine. My notes indicated I was seeing the following sequence (I have hwnds or whatever spy logs written down): Tooltip sends toolbar needtextW Sends to base class tbn_GetInfoTipA which didn't return anything Sends tbn_GetInfoTipA to its parent which didn't return anything Tooltip sends baseclass ttn NeedTextA Which forwards to parent as ttn NeedTextA My notes and investigations could be wrong, does this tie up with what you were seing? Jason
ATI fglrx 8.42 Driver issues
Hello wine crew, Not sure how many of you are ATI card users, but they released a new version of their binary driver a few days ago. It provides some great performance increases in native apps like Enemy Territory: Quake Wars, but I encountered a pretty serious problem when trying to wine World of Warcraft in OpenGL mode. In short, it won't draw models - it seems to draw environments and effect animations fine, but characters and objects like benches and mailboxes are invisible. It seems the majority of the focus is on testing at this point, but if there is any additional information I can provide which would help you graphics guys (available OpenGL extensions, etc.) please let me know. It's about time I contributed something to the project. =) Thanks, Brian Dunne
Re: [PATCH] Currently the serial code interprets
Hi Tom, Content-Type: text/x-patch; name=0001-XONXOFF-reversion.patch Content-Transfer-Encoding: base64 Apparently gmail's encoding .patch files as base64. It should be text/plain. Please try renaming it to, e.g., 0001-XONXOFF-reversion.diff and try again. --Juan
Convincing Valgrind to give a stack dump?
Looking at the app in bug 10125, using warn+heap, I saw a few of those scary-but-sometimes-harmless warnings, so I thought I'd give it a shot under Valgrind. After applying enough suppressions, I did find three interesting valgrind warnings: 10 errors in context 5 of 9: Conditional jump or move depends on uninitialised value(s) at 0x477F7F6: RedrawWindow (painting.c:612) 29 errors in context 7 of 9: Conditional jump or move depends on uninitialised value(s) at 0x43E4E6D: HEAP_ValidateInUseArena (heap.c:917) 184 errors in context 9 of 9: Conditional jump or move depends on uninitialised value(s) at 0x61F3CD0: XcursorImageHash (in /usr/lib/libXcursor.so.1.0.2) The commandline I used was WINEDEBUG=+process valgrind -v --error-limit=no --trace-children=yes --suppressions=$HOME/suppressions ~/wine-git/wine Olb.exe (+process was used to show that the errors in question did indeed come from olb.exe and not something it launched.) But I couldn't coax Valgrind into giving stack dumps for those errors; it acted as if it had seen a few too many errors first, and only showed the one line. Grr. Anyone know how to coax valgrind into always giving a good stack dump? - Dan
Re: tools/widl/typegen.c pointer initialization
On Mon, Oct 29, 2007 at 01:26:45AM +0100, Gerald Pfeifer wrote: I think the question is whether a compiler can reasonably be expected to deduce that the source is fine. If that deduction involves solving the halting problem (or similar) hacking the source to avoid the warning actually doesn't occur to be that bad. ;-) Nope, you can't depend on the compiler to verify your code is correct. That's why you should try to write it in such a way that people can understand it. Hacking the code to make the compiler happy at the cost of making the code less clear is not a good idea. I think the real problem is that the code is just not clear enough. I've been meaning to add asserts. Where asserts are impractical: comments. Does this mean you are going to submit some patches to address this? If you tell me what options you build with and I can reproduce the warning then I'll be more than happy to try to fix it. I build widl with -W -Wall and get two warnings. One of which is in the bison-generated code; the other I sent a patch to silence and Alexandre rejected it.
re: tools/widl/typegen.c pointer initialization
Dan H. wrote: If you tell me what options you build with and I can reproduce the warning then I'll be more than happy to try to fix it. I build widl with -W -Wall and get two warnings. To get uninitialized warnings, you have to also specify optimization (-O2). Without -O, gcc doesn't do the analysis that can detect uninitialized variables. - Dan
re: RICHED20: fix test crash on WinXP-SP2
Alex Lasso wrote: First of several patches to make riched20 tests actually pass on Windows. Without your patch, make test crashes for me on Wine. Your patch fixes the crash. So this isn't just a problem on Windows, thanks for fixing it! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
somewhere between release 0.9.46 and 0.9.47 of wine i started having problems with applications that use opengl. using git-bisect i found that commit 00633e37bcc8da1032f34ea2d87814739de07db4 (winex11: Use an offscreen redirected window for child OpenGL rendering.) was the first bad commit. in particular i am trying to run tracked part of racer 0.5.0 final (http://racer.nl/dl_win32.htm). doing a git-checkout 00633e37bcc8da1032f34ea2d87814739de07db4 and running tracked i get the following crash when i try to import a track: wine: Unhandled page fault on read access to 0x0014 at address 0x7e542141 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x0014 in 32-bit code (0x7e542141). fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e542141 ESP:0033fdb4 EBP:0033fdec EFLAGS:00210246( - 00 -RIZP1) EAX: EBX:7e578714 ECX:494c EDX: ESI:0001 EDI:0014da98 Stack dump: 0x0033fdb4: 00aa 001e 0x0033fdc4: 0041fa7d 0049 0x0033fdd4: 0014da98 0042567c 004256b5 7ed1f980 0x0033fde4: 0001 0014da98 0033fe0c 7ed072db 0x0033fdf4: 0033fe60 00443457 00408fa0 0x0033fe04: 7ed07299 0033ff08 0041b192 Backtrace: =1 0x7e542141 X11DRV_wglFlush+0x31() [/home/romosan/cvs/wine/dlls/winex11.drv/opengl.c:1952] in winex11 (0x0033fdec) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) 2 0x7ed072db wine_glFlush+0x4b() [/home/romosan/cvs/wine/dlls/opengl32/wgl.c:584] in opengl32 (0x0033fe0c) 3 0x0041b192 in tracked (+0x1b192) (0x0033ff08) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value
Re: Wine Gecko packaging
Jacek Caban [EMAIL PROTECTED] wrote: As you probably have noticed, downloading Gecko on first use confuses users. Now, with last week patches, there is an other way to do it, transparent for users. MSHTML code looks for cab file in $data_dir/gecko (that is usually /usr/share/wine/gecko). Alternatively, if you run Wine from build dir, it looks for $build_dir/../gecko. Wine checks it both in wineprefixcreate and, if Gecko is not installed, on first usage. It means that if you download wine_gecko-0.1.0.cab from SourceForge and put it in the right place, you will no longer have to care about installing Gecko. http://source.winehq.org/winegecko.php still points to an old Gecko package (0.0.1). Please update it. -- Dmitry.
Re: opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
On Sunday 28 October 2007 08:00:19 pm Alex Romosan wrote: somewhere between release 0.9.46 and 0.9.47 of wine i started having problems with applications that use opengl. using git-bisect i found that commit 00633e37bcc8da1032f34ea2d87814739de07db4 (winex11: Use an offscreen redirected window for child OpenGL rendering.) was the first bad commit. in particular i am trying to run tracked part of racer 0.5.0 final (http://racer.nl/dl_win32.htm). doing a git-checkout 00633e37bcc8da1032f34ea2d87814739de07db4 and running tracked i get the following crash when i try to import a track: What card do you have and what drivers are you using? It looks like it's trying to call glFlush without a context set, which is illegal. Have you filed a bug report on buzilla?
Re: opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
Chris Robinson writes: On Sunday 28 October 2007 08:00:19 pm Alex Romosan wrote: somewhere between release 0.9.46 and 0.9.47 of wine i started having problems with applications that use opengl. using git-bisect i found that commit 00633e37bcc8da1032f34ea2d87814739de07db4 (winex11: Use an offscreen redirected window for child OpenGL rendering.) was the first bad commit. in particular i am trying to run tracked part of racer 0.5.0 final (http://racer.nl/dl_win32.htm). doing a git-checkout 00633e37bcc8da1032f34ea2d87814739de07db4 and running tracked i get the following crash when i try to import a track: i forgot to cc the list so here we go in case somebody else finds this of interest: What card do you have and what drivers are you using? It looks like it's trying to call glFlush without a context set, which is illegal. this was on my thinkpad t40 with a radeon r250 (mobility firegl 9000) card using the open source drivers. the program also crashes on my desktop with an nvidia card using the proprietary nvidia drivers but i don't know if it's the same problem. i'll investigate more tomorrow. also, i am using xorg 7.3 from debian. i've been having this problem for about a month now which is about the time debian switched to xorg 7.3. i wonder if maybe this has something to do with the crash. Have you filed a bug report on buzilla? not yet. i first wanted to see what other people thought about this. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
