GNOME Bugzilla – Bug 501518
VTE with Native GTK+ on OSX not working
Last modified: 2007-12-05 09:00:38 UTC
Please describe the problem: VTE compiles fine against the native versions of GTK+ on OSX, but when trying to run any program (in particular the test program vte that is compiled with the library), no window opens. In particular, I think I have narrowed it down to (at least) two distinct problems 1. It never returns from vte_terminal_fork_command(). The call stack for this problem is listed below. 2. When using vte_terminal_fork_pty, I don't think things are drawing properly. I am pretty sure that if I input data that it is being accepted because the scroll bar begins to move after type <ENTER> several times. I tried messing around with a whole slew of color and other setting with no success. So, it has a black background and I can't get anything to draw in the foreground. Steps to reproduce: 1. Compiled VTE with 'configure --without-x --enable-debug' while in the GTK+-quartz jhbuild shell environment For problem (1) 2. Run 'vte -d' 3. It appears to hang. If running inside the debugger and I break, it is always as indicated in the call stack below. For problem (2) 2. Run 'vte -S' 3. A window pops up, but t looks incomplete and text is never drawn Actual results: Expected results: Does this happen every time? Yes Other information: The call stack for Problem (1)
+ Trace 180707
Further investigation shows some strange parameters mess-ups in one of the function calls. However, this relates more to the interaction between fork_exec_with_pipes() and read_ints(), rather than something in VTE. In the fork_exec_with_pipes() function line 1309, there is the following function call: if (!read_ints (child_err_report_pipe[0], buf, 2, &n_ints, error)) goto cleanup_and_fail; However, when breaking inside the read_ints() function and inspecting various variables, the third parameter (called n_ints_in_buf in the read_ints() parameter list) is *not* equal to 2 as expected. Instead it has a value of -1766845373 as shown in the call stack.
+ Trace 180720
I messed around with a calculator to see if this number was some strange 2's complement of 2 or something like that, but with no success. So this may or may not give insight into the problem, but it looked like a likely culprit to me.
No idea. Anyone with OS X can give it a try? Richard?
Yep, this is a dup of a glib bug. *** This bug has been marked as a duplicate of 495589 ***