Re: problem about SIGSEGV and backtrace
On Mon, Aug 06, 2007 at 11:10:46AM +0800, [EMAIL PROTECTED] wrote: > I want to use SIGSEGV and backtrace to debug my programme. But I do not > know how to use them. I'm running GTK 2.6.4 and Glib 2.6.4 on a Debian woody. > > Could you please guide me and tell where to find what I am looking for? Compile with -ggdb flag. ulimit -c unlimitied Let it crash. gdb PROGRAM_EXECUTABLE CORE_FILE bt Details: http://sourceware.org/gdb/current/onlinedocs/gdb_toc.html However, to see the stack trace dump on bad memory accesses, it is easier to just run the program under valgrind, an addition you will see also those that do not cause an immediate segmentation fault. Yeti -- http://gwyddion.net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
problem about SIGSEGV and backtrace
Hi all: I want to use SIGSEGV and backtrace to debug my programme. But I do not know how to use them. I'm running GTK 2.6.4 and Glib 2.6.4 on a Debian woody. Could you please guide me and tell where to find what I am looking for? Any help will be most appreciated. Thanks a lot. 你 玩 过 大 富 翁 吗？与 朋 友 网 络 对 战，还 能 一 起 挑 战 GM >> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed "busy" cursor
Paul Fox wrote: > paul davis wrote: > > On Sun, 2007-08-05 at 12:56 -0400, Paul Fox wrote: > > > > google gtk timeout -> gtk_timeout_add -> gtk.org/api -> Main Loop & > > Events -> "gtk_timeout_add has been deprecated since version 2.4 and > > should not be used in newly-written code. Use g_timeout_add() instead." > > > > and no, these run synchronously with the main loop, which is why they > > are safe to use. > > thanks -- i'll do some reading. at the moment, i'm not sure how > this will work. if i set a gtk timeout for 1 second, but my > program's "think" time is 10 seconds, then i won't get back to > the event loop until after that, and i've therefore blown my > intended timeout. During this think time, the GTK main loop cannot run, so yes, your timeout won't fire. But at the same time your app won't respond to the user either. It's just going to appear to be hung. This is generally considered bad. > > but i've probably just given myself away as the gtk newb that i > am, and am probably missing something really obvious, so i'll go > do some reading, like i said. > > (i'm actually kind of surprised there's no gdk_window_set_cursor_after_delay() > call, for just this purpose. :-) Even if there was, it wouldn't do any good in this case, as your app is spending those 10 seconds hogging the CPU, and never giving control to the main loop. So it wouldn't possibly have a chance to run, even if such a call existed. Just a note of caution. Threaded programming with GTK has be careful. Calling GTK calls from threads is problematic, and not cross-platform to boot. The recommended way is probably to use g_idle_add calls from the thread to notify the GUI loop of things, and using asyncqueues (a glib primitive) to pass data back and forth between the long-running task and the gui. Either that, or iterate the GTK main loop every so often from within your long-running task. Michael > > paul > =- > paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 74.1 degrees) > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed "busy" cursor
Hi Paul, On Sun, 05 Aug 2007 14:02:22 -0400 you wrote: > thanks -- i'll do some reading. at the moment, i'm not sure how > this will work. if i set a gtk timeout for 1 second, but my > program's "think" time is 10 seconds, then i won't get back to > the event loop until after that, and i've therefore blown my > intended timeout. If your program is doing something that will take it 10 seconds, you need to adjust your architecture to shift that operation out of the loop. Either: - Split the big think into lots of little chunks - Let the GTK main loop get a shot in between them or: - Move the complex thinky bit into another thread - Send a completion notification when it's done. For the first method you should use g_idle_add to put the iteration of chunks into free time. This leaves GTK running properly and doing your hard stuff when there's nothing else to update. For the second, the rule of thumb is that only the main thread should ever do a GTK call. Passing status from the worker thread can be done in several ways, but it's not a GTK issue. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed "busy" cursor
paul davis wrote: > On Sun, 2007-08-05 at 12:56 -0400, Paul Fox wrote: > > google gtk timeout -> gtk_timeout_add -> gtk.org/api -> Main Loop & > Events -> "gtk_timeout_add has been deprecated since version 2.4 and > should not be used in newly-written code. Use g_timeout_add() instead." > > and no, these run synchronously with the main loop, which is why they > are safe to use. thanks -- i'll do some reading. at the moment, i'm not sure how this will work. if i set a gtk timeout for 1 second, but my program's "think" time is 10 seconds, then i won't get back to the event loop until after that, and i've therefore blown my intended timeout. but i've probably just given myself away as the gtk newb that i am, and am probably missing something really obvious, so i'll go do some reading, like i said. (i'm actually kind of surprised there's no gdk_window_set_cursor_after_delay() call, for just this purpose. :-) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 74.1 degrees) ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed "busy" cursor
On Sun, 2007-08-05 at 12:56 -0400, Paul Fox wrote: google gtk timeout -> gtk_timeout_add -> gtk.org/api -> Main Loop & Events -> "gtk_timeout_add has been deprecated since version 2.4 and should not be used in newly-written code. Use g_timeout_add() instead." and no, these run synchronously with the main loop, which is why they are safe to use. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed "busy" cursor
paul davis wrote:
> On Sun, 2007-08-05 at 11:20 -0400, Paul Fox wrote:
> > hi --
> >
> > i want the mouse cursor in my app to only switch to "busy" after
> > a brief delay (perhaps 1 second). i have an implementation that
> > works in some places, but not others, and i'm wondering if
> > there's a better/safer way.
>
> >if (newcursor == CURSOR_BUSY_WITH_DELAY) {
> > signal(SIGALRM, busy_cursor_handler);
> > alarm(1);
>
> this is unsafe coding. POSIX signal handlers should do almost nothing,
> and they should certainly not call GTK functions.
>
> investigate the use of timeouts within GTK itself, which are *much*
> better suited for this purpose.
okay, thanks -- that confirms my suspicions (and results :-).
will these timeouts (can you point me at an API function i can
search for?) work asynchronously to the main event loop?
paul
=-
paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 72.9 degrees)
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed "busy" cursor
On Sun, 2007-08-05 at 11:20 -0400, Paul Fox wrote:
> hi --
>
> i want the mouse cursor in my app to only switch to "busy" after
> a brief delay (perhaps 1 second). i have an implementation that
> works in some places, but not others, and i'm wondering if
> there's a better/safer way.
>if (newcursor == CURSOR_BUSY_WITH_DELAY) {
> signal(SIGALRM, busy_cursor_handler);
> alarm(1);
this is unsafe coding. POSIX signal handlers should do almost nothing,
and they should certainly not call GTK functions.
investigate the use of timeouts within GTK itself, which are *much*
better suited for this purpose.
--p
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
implementing a delayed "busy" cursor
hi --
i want the mouse cursor in my app to only switch to "busy" after
a brief delay (perhaps 1 second). i have an implementation that
works in some places, but not others, and i'm wondering if
there's a better/safer way.
in my first cut at implementing this i fell back on old habits,
namely, signal handlers. i know using signals within gui apps is
risky -- and in fact the app implements the "handle signals via
an event pipe" trick to deal with SIGTERM, for this very reason.
but that trick won't work for the busy cursor delay, which really
needs to be asynchronous to program execution.
here's my current code:
void busy_cursor_handler(int signal)
{
set_my_cursor (CURSOR_BUSY);
}
void set_my_cursor (int newcursor)
{
GdkCursor *cursor;
static int lastcursor;
static int delayed;
if (delayed) {
alarm(0);
delayed = 0;
}
if (newcursor == CURSOR_BUSY_WITH_DELAY) {
signal(SIGALRM, busy_cursor_handler);
alarm(1);
delayed = 1;
return;
}
if (newcursor == lastcursor)
return;
lastcursor = newcursor;
switch (newcursor) {
case CURSOR_NORMAL:
cursor = NULL;
break;
case CURSOR_BUSY:
cursor = gdk_cursor_new(GDK_WATCH);
break;
}
gdk_window_set_cursor(MainWindow->window, cursor);
if (cursor) {
gdk_cursor_destroy(cursor);
}
gdk_flush();
}
the app looks roughly like:
...
set_my_cursor(CURSOR_BUSY_WITH_DELAY);
...do stuff that may or may not take a long time (the program
is a mapping program, so processing the data which needs to
be rendered can be costly), which includes calls to gdk and
gtk drawing functions made to update a DrawingArea widget.
the final call is to gtk_widget_draw() to paint it on the
screen...
set_my_cursor(CURSOR_NORMAL);
...
this all seems to work very solidly in "current" (as in, ubuntu
feisty up-to-date) versions of both GTK 1.2 (1.2.10-18) and GTK2
(2.10.11). this testing was done on a modern x86 laptop (1.6Ghz)
but when i run it on an older GTK 1.2 (1.2.10-17) from debian
sarge, i regularly get lockups, with the app spinning in a loop
down in the X libraries somewhere (i don't have a backtrace
handy). this testing was on a slow handheld device (400Mhz
au1100 mips).
is it possible that the minor revision difference for gtk1.2
could have fixed this problem? somehow i'm skeptical, and
suspect that the problem exists everywhere, but is being exposed
on the older slower hardware.
i tried modifying the above code so that only the gdk_flush()
happened during the signal handler (i even tried changing it
to "XFlush(GDK_DISPLAY())"), but i still get the lockups.
i figure i have several choices:
- live with restricting the feature to newer versions of GTK,
if indeed it's a problem that's been fixed in newer
releases, and if i can easily determine the version
level at runtime.
- add a user-configurable option to suppress the delay
feature if the user determines it causes lockups. (ugh.)
- implement the delayed busy cursor in a different way
guaranteed to work everywhere. is my implementation
using signals way off base? is there a more standard way
of doing this? my googling came up short.
many thanks.
paul
=-
paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 69.4 degrees)
'02 V-Strom, DoD #1462, AMA #545601
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 'reloading' gtktreeview when model changes drastically
On Sun, 2007-08-05 at 04:24 +0200, Milosz Derezynski wrote:
> Just FWIW, can we agree on one meaning of "transactional"?
> For me, the fact that the model shouldn't have to know about the
> number of views showing it has nothing to do with transactionality:
>
> > there may be multiple views on the model, and when changing the
> model, one
> > should not be required to know about the number of views. excellent
> > point, end of story for me. it ought to be "transactional".
>
> I think the most sensible meaning is the one we e.g. know from SQL and
> which Kris mentioned: One atomic changeset which can be "committed" to
> the model in one run. (It can probably not be rolled back, or if it
> would be possible, then it'd be quite expensive, but that's not really
> the point anyway).
For me, what is important is that MVC is that what it is supposed to be:
-> View observes Model
And not:
-> Some extra code done by the application developer observes for
the View the Model, because the View can't cope with the actual
MVC paradigm.
The simplicity of MVC is also what makes it so useful. By assuming that
the application developer will "solve" all the problems that the normal
"View observes Model" solves (he has to reset the model, he has to reset
the view's state, he has to detect changes to the model, ...) you void
the simplicity.
If the view internally actually resets its model, then that's fine.
It's a complexity that got solved by the View and didn't have to be
solved by the application developer. If it's more easy for Kris to
internally swap the Model (reloading everything and recovering the
state, like sorting --in case of a sortable -- or selection details),
then that's fine from the application developer's point of view.
> As for the model-should-be-view-ignorant issues, they have nothing to
> do with transactions, but are just as valid concerns of course.
>
>
> On 8/5/07, Paul Davis <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-08-05 at 00:25 +0200, Philip Van Hoof wrote:
> > On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> > > On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
> > >
> > > > The model itself is the source. The view is just a
> viewer for it. The
> > > > source itself doesn't change. The content of the source
> changes. The
> > > > view, being an observer of the model in the MVC
> paradigm, should adapt
> > > > to the changes. It should not require a sudden set and
> unset of its
> > > > model.
> > >
> > > I'm a big user of MVC. Although on some level I agree with
> you, I would
> > > ask what the difference is between:
> > >
> > > void gtk_treeview_freeze (GtkTreeView* tv) {
> > > /* store model in tv, then unset */
> > > }
> > > void gtk_treeview_thaw (GtkTreeView* tv) {
> > > /* reset model in tv */
> > > }
> >
> > Owk .. it's a bit lengthy and there are a lot of "personal
> opinions
> > about MVC" embedded in this one:
>
> it didn't need to be so lengthy :) thats why i noted that i
> use MVC a
> *lot* myself. the key point you raise is one that i had
> forgotten: there
> may be multiple views on the model, and when changing the
> model, one
> should not be required to know about the number of views.
> excellent
> point, end of story for me. it ought to be "transactional".
>
> --p
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
> ___
> gtk-devel-list mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 'reloading' gtktreeview when model changes drastically
As a somewhat related topic (this thread seems to not be nailed on a very
specific topic yet and this still fits in i think), a changeset+commit API
(in the truer sense; not what was proposed with just saying "all nodes below
this one have changed") would be _very_ welcome for gtkmm, because right
now, setting row data looks like this (snippet from our code):
--snip--
void
Playlist_V::put_track_at_iter (Track const& track,
Gtk::TreeModel::iterator & iter)
{
(*iter)[m_track_cr.track] = track;
(*iter)[m_track_cr.uid] = track.bmpx_track_id;
(*iter)[m_track_cr.localUid] = m_localUid;
(*iter)[m_track_cr.searchKey] = track.title ? track.title.get() :
std::string();
(*iter)[m_track_cr.playTrack] = track.active.get();
--snip--
And yes, this is exactly how it looks like: The row is accessed for each of
those lines, and each uses a separate call to list_store_set() internally.
Yes, it i disastrous to performance. One guy on the gtkmm-devel list
recently made a benchmark and found that the gtkmm way of doing this is
approximately 75 times (not 75% -- 75 times) slower than the C Gtk+ method.
Now without going to deep into C++, let's just say that with the way gtkmm
at least works, if not to be sane C++ altogether, it's not possible to have
a C-like TreeModel API in gtkmm, and that's where the changesets come in.
I've been already thinking of a transactional system for TreeModel, and i
have some ideas, but nothing that could be put to code right now.
_However_, a native API for this in C TreeModel (perhaps an additional
interface to TreeModel? "GtkTreeModelTransactional"?) would make this task
very simple because then it could be normally wrapped without needing
gtkmm-specific API.
Kris if you are really on to having a TreeModelTransactional Iface, please
just say "yeah", and i'll also start working on something (deadchip in
#gtk+, btw). This would be a major help for the other discussed problems
here, as well as for this one.
-- Milosz
On 6/24/07, Kristian Rietveld <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jun 19, 2007 at 12:45:09PM +0100, Peter Clifton wrote:
> > This seems to break the MVC abstraction - if the model changes
> > drastically, I need to know which tree-views are connected so I can
> > disconnect them? Bad!
> >
> > We need some new API I guess - which signals any connected views that
> > the data it has cached about the model should be invalidated, and that
> > the model may be changing without emitting signals.
> >
> > Once the model is updated, a further signal will inform the view that it
> > can keep cached state again.
>
> In practise this won't be all that different compared to setting a new
> model on the tree view, except that with a signal it will be initiated
> from the model. After the model emits the "I am finished changing
> everything" signal, the tree view will have to rebuild its internal
> rbtree by iterating over the full model again (any other model that is
> connected to this model will have to rebuild its internal state tree
> too), since it has no clue what has changed. This will probably also
> involve unreferencing all nodes when the model emits "invalidate" and
> re-reference the new nodes after the mass changing, and remembering
> selection and expansion state during the mass-changing (this information
> is kept in the internal rbtree too), etc.
>
> I think a much better solution would be to be able to group a bunch of
> changes together in a kind of "atomic changeset" which is then emitted
> with a single signal. All connected views/models could then process the
> full changeset in one pass. (Possibly this could also add/remove ranges
> of nodes, etc).
>
>
> regards,
>
> -kris.
> ___
> gtk-devel-list mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 'reloading' gtktreeview when model changes drastically
On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
>
> > The model itself is the source. The view is just a viewer for it. The
> > source itself doesn't change. The content of the source changes. The
> > view, being an observer of the model in the MVC paradigm, should adapt
> > to the changes. It should not require a sudden set and unset of its
> > model.
>
> I'm a big user of MVC. Although on some level I agree with you, I would
> ask what the difference is between:
>
> void gtk_treeview_freeze (GtkTreeView* tv) {
> /* store model in tv, then unset */
> }
> void gtk_treeview_thaw (GtkTreeView* tv) {
> /* reset model in tv */
> }
Owk .. it's a bit lengthy and there are a lot of "personal opinions
about MVC" embedded in this one:
Well I'm in favour of having a strict separation between code that views
data (the view), and code that represents the data (the model).
If you require that "using the model" is to be adapted or adjusted to
certain limitations, you are requiring that the model's code becomes
specific for the view. Let me explain:
Let's take the example with a person and a view for a person:
Person p = new Person ();
PersonView v1 = new PersonView ();
v1.Model = p;
I have another PersonView open on (another) screen (whether it's another
computer or another process or another whatever is irrelevant for now):
PersonView v2 = new PersonView ();
v2.Model = p;
Imagine I'm working at the p's town administration and I change person
p's name. Let's say we did this in v1.
We'll assume a simple system where each person has one instance in this
global system or where each system gets notified by triggers on the
remote database (quite Utopical, I know. But it's irrelevant. You can
also imagine one computer, one application with two PersonView instances
being visible at the same time, showing the same model -- the same
person instance, as we got the instance from a factory and the instance
is, indeed, the exact same instance --).
In v1's instance (image on_name_textbox_changed indeed happens) :
public class PersonView
{
public Person Model;
private void on_name_textbox_changed (TextBox o, ...) {
this.Model.Name = o.Text;
}
}
Note that maybe some people want to do this with a separate Controller
type, in which case we're in the exact same situation.
Now if we'd require that you always now refresh v1 and v2's model before
either v1 OR v2 (not "AND", because v1 can indeed update itself in the
on_name_textbox_changed method, but since PersonView should rather
observer its Model, we usually don't do this --but it can, I know--) ...
... how will v2 get itself updated in time?
It can't, because the view requires getting updated by having it set its
model each time it needs an update.
Now this is a simple example. Whether model is a list of rows, a tree of
things, a bear, a person, a traffic light (which is a typical example),
a remote control for a television ...
Whether the model is a list of 800,000 E-mails. Whether its 300,000 song
titles, ...
Doesn't matter for the MVC theory. You can always have a v1 and a v2
showing the same model instance.
When v1 causes a change to its model, and v2 shares the same instance as
model with v1, v2 should update itself instantly. Because both v1 and v2
observe the model.
Now the "update" (which gets called by the notify of the observable
model) of PersonView can of course do this internally (resetting its
model, resetting its state, doing this or doing that). That's just an
implementation detail.
In case of GtkTreeView this would mean that GtkTreeView would have to
implement this implementation detail. Not the application developer.
In GtkTreeView's case, if the changes are big .. its right now only
practical (else the performance is very weak, yadi yada) if you unset
the model and reset the model. But that's broken as illustrated in the
example above.
> and just calling gtk_treeview_set_model (NULL) and
> gtk_treeview_set_model (NOTNULL).
>
> there are additional issues: freeze/thaw semantics require use of a
> counter, so that, for example, if 3 nested contexts call "freeze", only
> the 3rd subsequent call to "thaw" actually unfreezes. contrast this to
> the simplicity of code in which only the top level sets+unsets the
> model, and all lower levels act on the model regardless of whether its
> connected to a view or not.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 'reloading' gtktreeview when model changes drastically
On Sun, 2007-08-05 at 00:32 +0200, Milosz Derezynski wrote:
> --snip--
> void
> Playlist_V::put_track_at_iter (Track const& track,
> Gtk::TreeModel::iterator & iter)
> {
> (*iter)[m_track_cr.track] = track;
> (*iter)[m_track_cr.uid] = track.bmpx_track_id ;
> (*iter)[m_track_cr.localUid] = m_localUid;
> (*iter)[m_track_cr.searchKey] = track.title ?
> track.title.get() : std::string();
> (*iter)[m_track_cr.playTrack] = track.active.get();
> --snip--
>
> And yes, this is exactly how it looks like: The row is accessed for
> each of those lines, and each uses a separate call to list_store_set()
> internally. Yes, it i disastrous to performance. One guy on the
> gtkmm-devel list recently made a benchmark and found that the gtkmm
> way of doing this is approximately 75 times (not 75% -- 75 times)
> slower than the C Gtk+ method.
Youch. And I recently changed Tasks from append/set/implicit sort to
insert at index 0/implicit sort because it is visibly faster on slower
devices (as well as leading to cleaner code, no more row-inserted events
with unset data).
Ross
--
Ross Burton mail: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
