~ubuntu-branches/debian/jessie/glib2.0/jessie

« back to all changes in this revision

Viewing changes to docs/reference/glib/running.sgml

  • Committer: Bazaar Package Importer
  • Author(s): Gustavo Noronha Silva
  • Date: 2009-02-15 13:00:43 UTC
  • mfrom: (1.3.1 upstream) (69.1.10 intrepid)
  • Revision ID: james.westby@ubuntu.com-20090215130043-q47fbt3owmt42m2f
Tags: 2.18.4-2
* Release to unstable
* debian/rules:
- bump SHVER, since we are already forcing a 2.18.0 dependecy on the
  symbols introduced in the development versions
* debian/control.in:
- added Homepage and Vcs-* control fields

Show diffs side-by-side

added added

removed removed

Lines of Context:
149
149
                  which performs sanity checks on the released memory slices.
150
150
                  Invalid slice adresses or slice sizes will be reported and lead to
151
151
                  a program halt.
152
 
                  This option should only be used in debugging scenarios, because it
153
 
                  significantly degrades GSlice performance. Extra per slice memory
154
 
                  is requied to do the necessary bookeeping, and multi-thread scalability
155
 
                  is given up to perform global slice validation.
156
 
                  This option is mostly useful in scenarios where program crashes are encountered
157
 
                  while GSlice is in use, but crashes cannot be reproduced with G_SLICE=always-malloc.
158
 
                  A potential cause for such a situation that will be caught by G_SLICE=debug-blocks
159
 
                  is e.g.:
 
152
                  This option is for debugging scenarios.
 
153
                  In particular, client packages sporting their own test suite should
 
154
                  <emphasis>always enable this option when running tests</emphasis>.
 
155
                  Global slice validation is ensured by storing size and address information
 
156
                  for each allocated chunk, and maintaining a global hash table of that data.
 
157
                  That way, multi-thread scalability is given up, and memory consumption is
 
158
                  increased. However, the resulting code usually performs acceptably well,
 
159
                  possibly better than with comparable memory checking carried out using
 
160
                  external tools. An example of a memory corruption scenario that cannot be
 
161
                  reproduced with <literal>G_SLICE=always-malloc</literal>, but will be caught
 
162
                  by <literal>G_SLICE=debug-blocks</literal> is as follows:
160
163
                  <programlisting>
161
164
                    void *slist = g_slist_alloc(); /* void* gives up type-safety */
162
165
                    g_list_free (slist);           /* corruption: sizeof (GSList) != sizeof (GList) */
191
194
  </para>
192
195
</formalpara> 
193
196
 
194
 
<formalpara id="G_WIN32_PRETEND_WIN9X">
195
 
  <title><envar>G_WIN32_PRETEND_WIN9X</envar></title>
196
 
 
197
 
  <para>
198
 
    Setting this variable to any value forces g_win32_get_windows_version()
199
 
    to return a version code for Windows 9x. This is mainly an internal 
200
 
    debugging aid for GTK+ and GLib developers, to be able to check the 
201
 
    code paths for Windows 9x.
202
 
  </para>
203
 
</formalpara> 
204
 
 
205
197
</refsect2>
206
198
 
207
199
<refsect2 id="setlocale">
227
219
On the other hand, there is the C library's current locale. The
228
220
character set (code-page) used by that is not necessarily the same as
229
221
the system default ANSI code-page. Strings in this character set are
230
 
returned by functions like <function>strftime</function>.
 
222
returned by functions like <function>strftime()</function>.
231
223
</para>
232
224
 
233
225
</refsect2>