Re: [bug-mdk] Bug in gmixvm

2009-10-06 Thread Jose Antonio Ortega Ruiz 
Stjepan Gros  writes:

> No need for coordination. When you release new version I'll repackage
> it. It is far less job to do than to create package from scratch. And
> if we find the error after you released 1.2.5 I'll add patch that will
> be shipped with package until you release new version with the patch
> applied.

OK. As an additional data point: a friend of mine has installed Fedora
11, and there a gmixvm with the initial update call deleted (as found in
the git repo, you may try that) starts immediately.

Thanks,
jao
-- 
Outside of a dog, a book is a man's best friend: and inside a dog,
it's too dark to read.
 - Groucho Marx


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk

Re: [bug-mdk] Bug in gmixvm

2009-10-06 Thread Stjepan Gros 
On Mon, Oct 5, 2009 at 1:44 PM, Jose Antonio Ortega Ruiz  wrote:
> Stjepan Gros  writes:
>
>> I tried it and it was the same.
>>
>> I also tried to recompile package on CentOS 5.2 and gmixvm there come
>> instantly. Turns out that this is something specific for fedora 11.
>
> Looks like that. It's not happening to me either on a Debian sid with
> gtk 2.18. Please, tell me if i can be of any further help chasing this
> problem. As an aside, there're some mostly unrelated and minimal changes
> in the git repo that will make the 1.2.5 release one of these days. I'm
> not sure what's the best way of coordinating here.

No need for coordination. When you release new version I'll repackage
it. It is far less job to do than to create package from scratch. And
if we find the error after you released 1.2.5 I'll add patch that will
be shipped with package until you release new version with the patch
applied.

Stjepan

> jao
> --
> Computer games don't affect kids; I mean if Pac Man affected us
> as kids, we would all be running around in darkened rooms, munching
> magic pills, and listening to repetitive electronic music.
>  - Kristian Wilson, Nintendo Inc.
>


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk

Re: [bug-mdk] Bug in gmixvm

2009-10-05 Thread Jose Antonio Ortega Ruiz 
Stjepan Gros  writes:

> I tried it and it was the same.
>
> I also tried to recompile package on CentOS 5.2 and gmixvm there come
> instantly. Turns out that this is something specific for fedora 11.

Looks like that. It's not happening to me either on a Debian sid with
gtk 2.18. Please, tell me if i can be of any further help chasing this
problem. As an aside, there're some mostly unrelated and minimal changes
in the git repo that will make the 1.2.5 release one of these days. I'm
not sure what's the best way of coordinating here.

jao
-- 
Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music.
 - Kristian Wilson, Nintendo Inc.


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk

Re: [bug-mdk] Bug in gmixvm

2009-10-05 Thread Stjepan Gros 
On Sun, Oct 4, 2009 at 7:36 PM, Jose Antonio Ortega Ruiz  wrote:
>
> Hi again, Stjepan. I've got another guess of what can be causing the
> initial disk scans, but, since i cannot reproduce them in my system, i
> would need your help, if you have the time.

I'll help, no problem...

> Could you comment out line number 14 in the file
> mixgtk/mixgtk_external.c (the one with a call to update_config_()) and
> see if that makes the problem go away?

I tried it and it was the same.

I also tried to recompile package on CentOS 5.2 and gmixvm there come
instantly. Turns out that this is something specific for fedora 11.

Stjepan

> Thanks a lot!
> jao
> --
> Like punning, programming is a play on words.
>  - Alan Perlis, Epigrams in Programing
>


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk

Re: [bug-mdk] Bug in gmixvm

2009-10-04 Thread Jose Antonio Ortega Ruiz 

Hi again, Stjepan. I've got another guess of what can be causing the
initial disk scans, but, since i cannot reproduce them in my system, i
would need your help, if you have the time.

Could you comment out line number 14 in the file
mixgtk/mixgtk_external.c (the one with a call to update_config_()) and
see if that makes the problem go away?

Thanks a lot!
jao
-- 
Like punning, programming is a play on words.
  - Alan Perlis, Epigrams in Programing


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk

Re: [bug-mdk] Bug in gmixvm

2009-10-01 Thread Jose Antonio Ortega Ruiz 
Stjepan Gros  writes:

>> What are the two ways of starting gmixvm? Do you have the same problem
>> starting (in a terminal) mixvm?
>
> Yes, it is the same no matter if I start it from CLI or from a menu entry.
>

I meant running the "mixvm" program, which is the CLI version of MDK's
MIX virtual machine.

>> Assembler=/usr/bin/mixasm -l %s
>> Mixasm=/usr/bin/mixasm -l %s
>> Editor=/usr/bin/xterm -e vi %s
>>
>> where, in all of them, the paths are to exisiting executables?
>
> I added those lines to gmixvm.config (and created it) but it is still
> scanning the /usr/bin directory. And just now I found out that it also
> stat's/lstat's many other files of which some do not exist. Here are
> some excerpts from the strace output:

[...]

So, my guess was not correct. All this disk trashing seems to be
happening inside gtk's initialisation code, before entering the main
loop. But i cannot reproduce it. Maybe it's related to some Gnome
daemon? I don't use Gnome: can you try starting gmixvm when logged on a
non-Gnome session and see what happens? (just shooting in the dark
here).

BTW, MDK is hosted at savannah, and bugs can be filled at



(although i'm not sure this is a MDK bug per se: the problem is
happening inside a call to gtk; i could be wrong though)

Cheers,
jao
-- 
It is easier to write an incorrect program than understand a correct
one.
  - Alan Perlis, Epigrams in Programing


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk

Re: [bug-mdk] Bug in gmixvm

2009-09-29 Thread Stjepan Gros 
On Tue, Sep 29, 2009 at 1:18 PM, Jose A. Ortega Ruiz  wrote:
>
> Hi Stjepan,
>
> Stjepan Gros  writes:
>
>> Hi!
>>
>> I'm trying to package mdk for Fedora and I'm almost there. :)
>
> Excellent!
>
>> The problem is that after running gmixvm it consumes much of disk and
>> CPU resources. I managed to find out that it's scanning the whole
>> directory tree (either /usr/bin or home directory, depending how it is
>> started).
>
> What are the two ways of starting gmixvm? Do you have the same problem
> starting (in a terminal) mixvm?

Yes, it is the same no matter if I start it from CLI or from a menu entry.

>> Attached is gdb stack trace. Do you know what could be the exact
>> problem?
>
> Hmmm... it's a bit difficult to tell, but i have a guess. It could be
> one of the gnome daemons looking for a path, or something like that. To
> check, could you edit ~/.mdk/gmixvm.config (creating it if necessary)
> and ensure that it contains the lines:
>
> Assembler=/usr/bin/mixasm -l %s
> Mixasm=/usr/bin/mixasm -l %s
> Editor=/usr/bin/xterm -e vi %s
>
> where, in all of them, the paths are to exisiting executables?

I added those lines to gmixvm.config (and created it) but it is still
scanning the /usr/bin directory. And just now I found out that it also
stat's/lstat's many other files of which some do not exist. Here are
some excerpts from the strace output:

access("/etc/fonts/conf.d/20-unhint-small-dejavu-lgc-sans.conf", R_OK) = 0
stat("/etc/fonts/conf.d/20-unhint-small-dejavu-lgc-sans.conf",
{st_mode=S_IFREG|0644, st_size=864, ...}) = 0
open("/etc/fonts/conf.d/20-unhint-small-dejavu-lgc-sans.conf", O_RDONLY) = 8
read(8, "\0\1\0\0\0\340\...@\0\0\0\0\0@"...,
4096) = 4096
close(13)   = 0
stat("/home/zavod/sgros/.thumbnails/normal/a710091ca4edfb17e916eced9711f33f.png",
0x7fff82a91470) = -1 ENOENT (No such file or directory)
stat("/home/zavod/sgros/.thumbnails/fail/gnome-thumbnail-factory/a710091ca4edfb17e916eced9711f33f.png",
0x7fff82a91470) = -1 ENOENT (No such file or directory)
lstat("/usr/bin/pdftoppm", {st_mode=S_IFREG|0755, st_size=21448, ...}) = 0
open("/usr/bin/pdftoppm", O_RDONLY) = 13
read(13, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0\340...@\0\0\0\0\0@"...,
4096) = 4096
close(13)   = 0
stat("/home/zavod/sgros/.thumbnails/normal/ffd35f2016dcc3c3e310a75b7eff6c09.png",
0x7fff82a91470) = -1 ENOENT (No such file or directory)
stat("/home/zavod/sgros/.thumbnails/fail/gnome-thumbnail-factory/ffd35f2016dcc3c3e310a75b7eff6c09.png",
0x7fff82a91470) = -1 ENOENT (No such file or directory)
lstat("/usr/bin/sbiload", {st_mode=S_IFREG|0755, st_size=18080, ...}) = 0
open("/usr/bin/sbiload", O_RDONLY)  = 13
read(13, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0\24...@\0\0\0\0\0@"...,
4096) = 4096
close(13)   = 0

open("/usr/bin/ntfsmove", O_RDONLY) = 13
read(13, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0\320...@\0\0\0\0\0@"...,
4096) = 4096
close(13)   = 0
stat("/home/zavod/sgros/.thumbnails/normal/ae0e5905f16b8c56928372e0b9a5e39a.png",
0x7fff82a91470) = -1 ENOENT (No such file or directory)
stat("/home/zavod/sgros/.thumbnails/fail/gnome-thumbnail-factory/ae0e5905f16b8c56928372e0b9a5e39a.png",
0x7fff82a91470) = -1 ENOENT (No such file or directory)
lstat("/usr/bin/veusz_listen", {st_mode=S_IFREG|0755, st_size=1082, ...}) = 0
open("/usr/bin/veusz_listen", O_RDONLY) = 13
read(13, "#!/usr/bin/python\n\n#Runs veus"..., 4096) = 1082
close(13)   = 0
stat("/home/zavod/sgros/.thumbnails/normal/69d160f964a7fa71e2c3cfee29f449f6.png",
0x7fff82a91470) = -1 ENOENT (No such file or directory)
stat("/home/zavod/sgros/.thumbnails/fail/gnome-thumbnail-factory/69d160f964a7fa71e2c3cfee29f449f6.png",
0x7fff82a91470) = -1 ENOENT (No such file or directory)
lstat("/usr/bin/lpq", {st_mode=S_IFLNK|0777, st_size=27, ...}) = 0

Stjepan

P.S. Bugzilla entry for Fedora package is here:

https://bugzilla.redhat.com/show_bug.cgi?id=520637

> Thanks!
> jao
> --
> Dealing with failure is easy: Work hard to improve. Success is also
> easy to handle: You've solved the wrong problem. Work hard to improve.
>  - Alan Perlis, Epigrams in Programing
>


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk

Re: [bug-mdk] Bug in gmixvm

2009-09-29 Thread Jose A. Ortega Ruiz 

Hi Stjepan,

Stjepan Gros  writes:

> Hi!
>
> I'm trying to package mdk for Fedora and I'm almost there. :)

Excellent!

> The problem is that after running gmixvm it consumes much of disk and
> CPU resources. I managed to find out that it's scanning the whole
> directory tree (either /usr/bin or home directory, depending how it is
> started).

What are the two ways of starting gmixvm? Do you have the same problem
starting (in a terminal) mixvm?

> Attached is gdb stack trace. Do you know what could be the exact
> problem?

Hmmm... it's a bit difficult to tell, but i have a guess. It could be
one of the gnome daemons looking for a path, or something like that. To
check, could you edit ~/.mdk/gmixvm.config (creating it if necessary)
and ensure that it contains the lines:

Assembler=/usr/bin/mixasm -l %s
Mixasm=/usr/bin/mixasm -l %s
Editor=/usr/bin/xterm -e vi %s

where, in all of them, the paths are to exisiting executables?

Thanks!
jao
-- 
Dealing with failure is easy: Work hard to improve. Success is also
easy to handle: You've solved the wrong problem. Work hard to improve.
  - Alan Perlis, Epigrams in Programing


___
bug-mdk mailing list
bug-mdk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mdk

[bug-mdk] Bug in gmixvm

2009-09-29 Thread Stjepan Gros 
Hi!

I'm trying to package mdk for Fedora and I'm almost there. :) The
problem is that after running gmixvm it consumes much of disk and CPU
resources. I managed to find out that it's scanning the whole
directory tree (either /usr/bin or home directory, depending how it is
started). Attached is gdb stack trace. Do you know what could be the
exact problem?

Stjepan


(gdb) run
Starting program: /usr/bin/gmixvm
warning: .dynamic section for "/usr/lib/libfreetype.so.6" is not at
the expected address
warning: difference appears to be caused by prelink, adjusting expectations
[Thread debugging using libthread_db enabled]
Missing separate debuginfo for /usr/lib/libtdb.so.1
Try: yum --enablerepo='*-debuginfo' install
/usr/lib/debug/.build-id/a9/d89f5a179340f6dc46499bbcdce21d2f85a644.debug
warning: "/usr/lib/debug/usr/lib/gconv/libJIS.so.debug": The separate
debug info file has no debug info
warning: .dynamic section for "/usr/lib/libibus.so.1" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/usr/lib/libfam.so.0" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations

(gmixvm:12652): GVFS-RemoteVolumeMonitor-WARNING **: invoking
IsSupported() failed for remote volume monitor with dbus name
org.gtk.Private.GduVolumeMonitor:
org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process
/usr/libexec/gvfs-gdu-volume-monitor received signal 11
warning: .dynamic section for "/usr/lib/libbeagle.so.1" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
[New Thread 0xb677fb70 (LWP 12788)]
[New Thread 0xb5bffb70 (LWP 12789)]
[New Thread 0xb4fffb70 (LWP 12790)]
[Thread 0xb677fb70 (LWP 12788) exited]
[Thread 0xb4fffb70 (LWP 12790) exited]
[Thread 0xb5bffb70 (LWP 12789) exited]
[New Thread 0xb5bffb70 (LWP 12851)]
[New Thread 0xb4fffb70 (LWP 12852)]
[New Thread 0xb677fb70 (LWP 12853)]
[Thread 0xb677fb70 (LWP 12853) exited]
[Thread 0xb5bffb70 (LWP 12851) exited]
^C
Program received signal SIGINT, Interrupt.
0x0556b0c3 in IA__gtk_tree_path_free (path=0x928fd58) at gtktreemodel.c:630
630 {
Missing separate debuginfos, use: debuginfo-install
GConf2-2.27.0-1.fc12.i686 cairo-1.8.8-3.fc12.i686 expat-2.0.1-7.i686
gamin-0.1.10-5.fc12.i686 gmp-4.3.1-5.fc12.i686
gtk2-engines-2.18.2-5.fc12.i686 gvfs-1.3.6-2.fc12.i686
ibus-gtk-1.2.0.20090915-1.fc12.i686
ibus-libs-1.2.0.20090915-1.fc12.i686 libXau-1.0.5-1.fc12.i686
libXcomposite-0.4.0-10.fc12.i686 libXcursor-1.1.10-1.fc12.i686
libXdamage-1.1.1-9.fc12.i686 libXfixes-4.0.3-8.fc12.i686
libXi-1.2.99-11.20090825.fc12.i686 libXinerama-1.0.99.1-1.fc12.i686
libXrandr-1.3.0-3.fc12.i686 libXrender-0.9.4-7.fc12.i686
libattr-2.4.43-4.fc12.i686 libbeagle-0.3.9-5.fc12.i686
libcanberra-0.17-2.fc12.i686 libcanberra-gtk2-0.17-2.fc12.i686
libcap-2.16-5.fc12.i686 libglade2-2.6.4-3.fc12.i686
libogg-1.1.4-2.fc12.i686 libselinux-2.0.86-2.fc12.i686
libtool-ltdl-2.2.6-13.fc12.i686 libudev-145-7.fc12.i686
libvorbis-1.2.3-2.fc12.i686 libxml2-2.7.4-2.fc12.i686
nss-softokn-freebl-3.12.4-9.fc12.i686 pango-1.25.6-1.fc12.i686
(gdb) thread apply all bt

Thread 6 (Thread 0xb4fffb70 (LWP 12852)):
#0  0x008fd416 in __kernel_vsyscall ()
#1  0x00513402 in pthread_cond_timedwait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:179
#2  0x00aa8faf in g_cond_timed_wait_posix_impl (cond=0xfdfc,
entered_mutex=0x75, abs_time=0xb4fff2c8) at gthread-posix.c:242
#3  0x006ca7ec in g_async_queue_pop_intern_unlocked (queue=0x80f32b0,
try=, end_time=0xb4fff2c8) at gasyncqueue.c:365
#4  0x006ca906 in IA__g_async_queue_timed_pop (queue=0x80f32b0,
end_time=0xb4fff2c8) at gasyncqueue.c:491
#5  0x0071c1f6 in g_thread_pool_wait_for_new_pool () at gthreadpool.c:121
#6  g_thread_pool_thread_proxy () at gthreadpool.c:324
#7  0x0071abf0 in g_thread_create_proxy (data=0x828f0a0) at gthread.c:635
#8  0x0050e9d5 in start_thread (arg=0xb4fffb70) at pthread_create.c:297
#9  0x0043565e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 1 (Thread 0xb7fca720 (LWP 12652)):
#0  0x0556b0c3 in IA__gtk_tree_path_free (path=0x928fd58) at gtktreemodel.c:630
#1  0x002fa4ff in traverse_cells (tree_view=,
tree_path=, set_stale=,
inc_row=) at gailtreeview.c:3782
#2  0x002fd030 in model_row_inserted (tree_model=, path=, iter=,
user_data=) at gailtreeview.c:2885
#3  0x05475719 in _gtk_marshal_VOID__BOXED_BOXED (closure=, return_value=,
n_param_values=, param_values=, invocation_hint=,
marshal_data=) at gtkmarshalers.c:1309
#4  0x007e9643 in IA__g_closure_invoke (closure=0x84cf3b8,
return_value=0x0, n_param_values=3, param_values=0x928a080,
invocation_hint=0xbfffe350)
at gclosure.c:767
#5  0x0080096e in signal_emit_unlocked_R (node=,
detail=, instance=0x84b44a0, emission_return=0x0,
instance_and_params=0x928a080) at gsignal.c:3317
#6  0x0080189d in IA__g_signal_emit_valist (instance=0x84b44a0,
signal_i