On Thu, 30 Mar 2000, you wrote:
> >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> I get the following output to the xterm. Any ideas what it
> Angus> means? Is it serious?
>
> It means that the program (probably xtl) reads data wrongly through
> dirty tricks. On an alpha, memory can only be read on addresses
> aligned on 4-bytes (is that 8?)boundaries. The command "uac p sigbus"
> will make lyx break at these points, and gdb will then be able to tell
> you where the problem is. I'd bet it will be in xtl. Report it to its
> author.
>
> JMarc
Where do you get this sort of information from. I'd never
even heard of uac. I'll take it as evidence that God is a
Frenchman, contrary to popular opinion over here.
Allan, if you're reading this, do you use something other
than an Alpha? If so, do you get these "Unaligned access"
errors.
Anyway, I've done as you suggested. The thing falls over
inside PrinterParams::get() or
PrinterParams::set(), or more precisely inside xtl (comment
continues beneath):
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
(gdb) r
Starting program: /usr/users/aleem/lyx/rae/src/lyx
...
No info about kb_action: 16
Unaligned access pid=3231 <lyx> va=11fffa92a pc=120154e40 ra=120154938 type=sts
Program received signal SIGBUS, Bus error.
LyXFunc::Dispatch (this=0x14008a860, action=536846912, size=1024,
buf=0x11fffa798 "\220��\037\001") at ../xtl/objio.h:313
313 format.output_chars(data.data(), size);
(gdb) l
308 }
309
310 inline obj_output& simple(const std::string& data) {
311 int size=data.size();
312 format.output_start_array(size);
313 format.output_chars(data.data(), size);
314 format.output_end_array();
315 return *this;
316 }
(gdb) where
#0 LyXFunc::Dispatch (this=0x14008a860, action=536846912, size=1024,
buf=0x11fffa798 "\220��\037\001") at ../xtl/objio.h:313
#1 0x120279470 in FormPrint::update (this=0x1400ba5c0) at FormPrint.C:116
#2 0x120283934 in HideBase::show (this=0x1400ba5c0) at HideBase.C:68
#3 0x120283d88 in SigC::ObjectSlot0_<void, HideBase>::callback (
d=0x11fffa240) at ../../../sigc++/object_slot.h:56
#4 0x12015878c in SigC::Signal0<void, SigC::Marshal<void> >::emit (
this=0x11fffa240) at ../sigc++/basic_signal.h:193
#5 0x12013ddc8 in LyXFunc::Dispatch (this=0x1400be400, ac=7,
do_not_use_this_arg=0x0) at ../sigc++/basic_signal.h:171
#6 0x1201707f8 in Menus::ShowFileMenu (ob=0x1400a2600) at menus.C:634
#7 0x12016dd30 in C_Menus_ShowFileMenu (ob=0x11fffa240, data=5369276512)
at menus.C:65
#8 0x3ffbff8caac in fl_object_qread ()
#9 0x3ffbff8afc4 in fl_check_forms ()
#10 0x120121868 in LyXGUI::runTime (this=0x11fffa240) at lyx_gui.C:591
#11 0x120125758 in LyX::LyX (this=0x11ffff568, argc=0x11ffff560,
argv=0x11ffff5c8) at ../src/lyx_main.C:130
#12 0x12016dc80 in main (argc=1, argv=0x11ffff5c8) at ../src/main.C:52
(gdb)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This may of course be a function of my using lyxstring
rather than STL string? How much would I need to hack the
code base to remove those calls to string::clear() I wonder?
Angus
