Request for help in organising/releasing source code

discuss PC<>Acorn file transfer issues & the use of FDC, XFER, Omniflop/disk etc.
User avatar
simonm
Posts: 209
Joined: Mon May 09, 2016 2:40 pm
Contact:

Re: Request for help in organising/releasing source code

Post by simonm » Sun Sep 16, 2018 5:47 pm

Richard Russell wrote:
Sun Sep 16, 2018 4:12 pm
That would certainly be very helpful to me.
As promised then, hopefully it is of some use!

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Mon Sep 17, 2018 9:01 am

simonm wrote:
Sun Sep 16, 2018 5:47 pm
hopefully it is of some use!
Yes, very interesting. There's one thing I'm not clear about: it states "For any repository you own, only you can make changes to the project" but if the project is added to the 'Stardot GitHub organisation' who can make changes then?

Coeus
Posts: 1079
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Request for help in organising/releasing source code

Post by Coeus » Mon Sep 17, 2018 6:49 pm

Richard Russell wrote:
Mon Sep 17, 2018 9:01 am
simonm wrote:
Sun Sep 16, 2018 5:47 pm
hopefully it is of some use!
Yes, very interesting. There's one thing I'm not clear about: it states "For any repository you own, only you can make changes to the project" but if the project is added to the 'Stardot GitHub organisation' who can make changes then?
I went reading the GitHub documentation. It seems things can be very flexiable but I suspect StarDot have stuck to defaults for many things so a simplified overview....

There are two common "grades" associated with an organisation: owners and members. Owner are like superuser on Unix-like systems. i.e. they can do anything with the organisation account including committing to all its repositories.

Members don't have any special privileges initially, because in a non-paid account all repositories are readable to the general public. However, an owner can assign commit access to one or more repositories to one or more members.

So it does not suddenly become a free-for-all to make changes but it does mean if we could not get hold of you for some time, changes could still be made because owners could either commit directly, possibly in response to a pull request from a member, or could grant a member commit access.

Of course, once you've published the source code there is nothing (technical*) to stop someone else from continuing to develop it independently, usually called "forking" so the question of control over the repository is about control over an "official home". If people do choose to fork it, GitHub provides a button which has the advantage that one can navigate from the original repository to the forks so see what they have been up to.

* I say technical because you could always withhold (reserve) the right to create derived works so doing that would be illegal but obviously that isn't common.

User avatar
BigEd
Posts: 2139
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Request for help in organising/releasing source code

Post by BigEd » Mon Sep 17, 2018 7:06 pm

Coeus wrote:
Mon Sep 17, 2018 6:49 pm
... you could always withhold (reserve) the right to create derived works ...
Might be worth noting that this is the default: things can't be copied unless the creator says they can be copied. For this reason it's really helpful to add a suitable license to your project or your source files.
Richard Russell wrote:
Wed Sep 12, 2018 6:42 pm
My objective is simply to put it into the public domain, so that it doesn't vanish when I die...
I'd suggest in this case choosing the CC0 license.

It should be understood - and probably already is, but here we go - that merely putting code in a public place, even github, does not change its copyright or licensing status, and does not put it in the public domain. There are people who would prefer not to have to even think about this kind of thing, who don't want to be bothered with 'legal stuff' - I understand the position, but to make it work you have to do something. CC0 is as close as you can get, sensibly, to saying 'do anything'. (There are other approaches but they are not nearly as useful.)

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Mon Sep 17, 2018 7:33 pm

BigEd wrote:
Mon Sep 17, 2018 7:06 pm
CC0 is as close as you can get, sensibly, to saying 'do anything'.
Since BBCSDL is so dependent on (and linked with, in some editions) SDL, there's an argument that using the same licence (zlib) would be sensible; I have no idea how it compares with CC0. But at the moment I can't see how putting my project on GitHub would achieve anything other than making my life more difficult than it is now! I can see the value to collaborative projects, but over the years I've asked over and over again for people to help me develop BBC BASIC, and nobody ever has.

User avatar
BigEd
Posts: 2139
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Request for help in organising/releasing source code

Post by BigEd » Mon Sep 17, 2018 7:53 pm

Having a project out in the open is a step towards getting contributors. It might not happen very soon, but it has every chance of happening. Seeing the code and wanting to work on it is a stimulus.

The zlib license would also be a reasonable choice. But choosing anything that's more permissive would serve the same end of interoperability - and CC0 is as permissive as they come.

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Mon Sep 17, 2018 9:41 pm

BigEd wrote:
Mon Sep 17, 2018 7:53 pm
Having a project out in the open is a step towards getting contributors. It might not happen very soon, but it has every chance of happening.
If it does happen it will probably be too late to be a 'collaboration' (with me, anyway!) because by then I expect I will either not be around any more, or not able to contribute in a useful way. :(

Releasing the source as a zip may not be as sophisticated as putting it on GitHub, but it has achieved what I set out to. Incidentally I have today updated the file to match the latest release of BBCSDL. The changes are as follows:
  1. The line-editor used by the INPUT and INPUT LINE statements (and in immediate mode) has been enhanced to support UTF-8.
  2. The socklib.bbc library now supports UDP as well as TCP.
  3. A new library utf8lib.bbc has been added with UTF-8 replacements for LEFT$, RIGHT$, MID$, INSTR and LEN.
  4. David Williams' 'Rainbow Snake' program has been added to the examples.
  5. A new example program 'lanchat.bbc' demonstrates the use of UDP for a serverless chat application.
For those not familiar with BB4W and BBCSDL UTF-8 support can be enabled using the VDU 23,22.... custom mode command. In conjunction with a suitable font this allow BBC BASIC to work with extended character sets (see unicode.bbc in the supplied examples).

User avatar
simonm
Posts: 209
Joined: Mon May 09, 2016 2:40 pm
Contact:

Re: Request for help in organising/releasing source code

Post by simonm » Tue Sep 18, 2018 10:06 am

Richard Russell wrote:
Mon Sep 17, 2018 9:41 pm
Releasing the source as a zip may not be as sophisticated as putting it on GitHub, but it has achieved what I set out to.
Absolutely, and a perfectly fine way to do it - entirely your prerogative how you want to distribute your own projects.
That said, you might wish to consider putting some type of license file into your source zip package, so that there's some means for you to specify terms of use.

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Tue Sep 18, 2018 11:38 am

simonm wrote:
Tue Sep 18, 2018 10:06 am
That said, you might wish to consider putting some type of license file into your source zip package
I've added the zlib licence, FWIW, although one of the few benefits of getting 'old' is that how one's software might or might not get used in the future is of little concern! I don't have any children or heirs who might care either.

User avatar
davidb
Posts: 2231
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Request for help in organising/releasing source code

Post by davidb » Tue Sep 18, 2018 11:53 am

My impression was that there are quite a few avid users of BBC BASIC for SDL and Windows, so you may find that one or more of them might be interested in helping with the language implementation. After all, the users are often the ones driving development. :)

User avatar
dhg2
Posts: 96
Joined: Tue Oct 25, 2016 7:37 pm
Contact:

Re: Request for help in organising/releasing source code

Post by dhg2 » Tue Sep 18, 2018 12:22 pm

over the years I've asked over and over again for people to help me develop BBC BASIC, and nobody ever has.
Now that there's source code available, there's an increased chance that people will start helping out in the future, as BigEd said.

Have you put a link to the source code zip archive on the BBCSDL webpage? I had a look but couldn't find it there. I'd suggest adding it there so your users who may not browse any forums can find it.
Regards,
- Patrick

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Tue Sep 18, 2018 1:07 pm

davidb wrote:
Tue Sep 18, 2018 11:53 am
My impression was that there are quite a few avid users of BBC BASIC for SDL and Windows, so you may find that one or more of them might be interested in helping with the language implementation. After all, the users are often the ones driving development. :)
Experience has shown it not to be the case. I suspect the main factor is the 'age profile' of the users of BB4W and BBCSDL: they tend to be in my age bracket or older (sometimes much older!).

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Tue Sep 18, 2018 1:36 pm

dhg2 wrote:
Tue Sep 18, 2018 12:22 pm
Have you put a link to the source code zip archive on the BBCSDL webpage?
Not as yet, no. I'm uneasy about drawing attention to a source package that isn't actually used to build the BBCSDL releases (with the exception of the Raspberry Pi edition, which was built from those sources this time), for fear of misleading people. At the moment keeping that source zip in sync with releases is an entirely manual process.

Over time I'll transition the Android and iOS editions to use the published sources (I'm very risk averse!) but the 32-bit x86 editions (Windows, Linux, MacOS) will continue to be built from the old sources, because of the speed benefit (something like x2) and the presence of an assembler.

Has anybody actually tried to build a working executable from the sources I published?

User avatar
bakoulis
Posts: 290
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece
Contact:

Re: Request for help in organising/releasing source code

Post by bakoulis » Tue Sep 18, 2018 3:26 pm

I tried to build on my Linux Mint 17.3 32-bit but it fails with errors.
Last edited by bakoulis on Tue Sep 18, 2018 3:26 pm, edited 1 time in total.
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

User avatar
dhg2
Posts: 96
Joined: Tue Oct 25, 2016 7:37 pm
Contact:

Re: Request for help in organising/releasing source code

Post by dhg2 » Tue Sep 18, 2018 4:16 pm

bakoulis wrote:
Tue Sep 18, 2018 3:26 pm
I tried to build on my Linux Mint 17.3 32-bit but it fails with errors.
It builds and runs on my laptop with Debian stable AMD64. Which errors did you get?
Regards,
- Patrick

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Tue Sep 18, 2018 4:42 pm

bakoulis wrote:
Tue Sep 18, 2018 3:26 pm
I tried to build on my Linux Mint 17.3 32-bit but it fails with errors.
I haven't included a 32-bit Linux makefile in the zip! Did you realise that and make the necessary changes first? I assumed that 32-bit Linux was so rare that there was little point including a suitable makefile (is there a way of detecting 32/64 bits so the makefile could be 'universal'?).

User avatar
bakoulis
Posts: 290
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece
Contact:

Re: Request for help in organising/releasing source code

Post by bakoulis » Tue Sep 18, 2018 9:28 pm

So, the problem was expected!
You haven't included makefile for 32bit linux or an universal makefile with 32/64 detection!
And I can't make changes on makefile myself.
Last edited by bakoulis on Tue Sep 18, 2018 9:28 pm, edited 1 time in total.
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

scruss
Posts: 58
Joined: Sun Jul 01, 2018 3:12 pm
Location: Toronto
Contact:

Re: Request for help in organising/releasing source code

Post by scruss » Wed Sep 19, 2018 12:31 am

Richard Russell wrote:
Tue Sep 18, 2018 4:42 pm
(is there a way of detecting 32/64 bits so the makefile could be 'universal'?).
From the shell

Code: Select all

getconf LONG_BIT
returns 32 or 64. From a Makefile, I do not know how.

Coeus
Posts: 1079
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Request for help in organising/releasing source code

Post by Coeus » Wed Sep 19, 2018 8:51 pm

bakoulis wrote:
Tue Sep 18, 2018 9:28 pm
And I can't make changes on makefile myself.
Because you don't know how to or because you fear it is not allowed? Ricard is releasing this under the zlib license so you are allowed to alter the makefike or create a parallel one for 32 bit.
Last edited by Coeus on Wed Sep 19, 2018 9:00 pm, edited 2 times in total.

Coeus
Posts: 1079
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Request for help in organising/releasing source code

Post by Coeus » Wed Sep 19, 2018 8:58 pm

Richard Russell wrote:
Tue Sep 18, 2018 1:36 pm
Has anybody actually tried to build a working executable from the sources I published?
It builds and runs on Arch Linux 64, as in it starts, lunches the IDE and would run a short type-in and a couple of others I had to hand.

In that respect this is an advance on the 32 bit package from the website which crashes inside SDL even with the 32 bit libraries installed.

Even if it was no better, now I would be able to debug it more easily and, if it turned out to be a libSDL bug, send in a bjg report to them that makes sense.

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Wed Sep 19, 2018 9:59 pm

Coeus wrote:
Wed Sep 19, 2018 8:58 pm
In that respect this is an advance on the 32 bit package from the website which crashes inside SDL even with the 32 bit libraries installed.
When you say "crashes" can you confirm that you're not talking about the D-Bus error referred to in the install.txt file? As it states there, on some systems you must execute 32-bit BBCSDL using:

Code: Select all

IBUS_ADDRESS=0 ./bbcsdl
If you're doing that and it still crashes, what error message are you receiving?

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Wed Sep 19, 2018 10:37 pm

scruss wrote:
Wed Sep 19, 2018 12:31 am
From the shell

Code: Select all

getconf LONG_BIT
OK, I have updated the Linux makefile to adapt automatically and it should now build a 32-bit or 64-bit executable successfully depending on the platform. However you may still need to run the 32-bit version using:

Code: Select all

IBUS_ADDRESS=0 ./bbcsdl
as documented here. I'm not aware that this issue is receiving much attention from SDL developers, perhaps because of the relative rarity of 32-bit Linux. Also, please be aware that the 32-bit executable available for download from the website contains an x86-32 assembler, whereas what you can build yourself from the sources doesn't (and runs at about half the speed).

User avatar
BigEd
Posts: 2139
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Request for help in organising/releasing source code

Post by BigEd » Thu Sep 20, 2018 7:12 am

Richard Russell wrote:
Wed Sep 19, 2018 10:37 pm
... you may still need to run the 32-bit version using:

Code: Select all

IBUS_ADDRESS=0 ./bbcsdl
BTW, a portability tip, as people may run different shells. This syntax is acceptable to all shells, AFAIK:

Code: Select all

env IBUS_ADDRESS=0 ./bbcsdl

User avatar
bakoulis
Posts: 290
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece
Contact:

Re: Request for help in organising/releasing source code

Post by bakoulis » Thu Sep 20, 2018 8:19 am

Still I can't build from source on 32bit linux.
I suspect the problem is from use of bbasmb_x86_64 assembler inside makefile.
If you need more, I can provide you the log with errors.
:(
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

Coeus
Posts: 1079
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Request for help in organising/releasing source code

Post by Coeus » Thu Sep 20, 2018 5:20 pm

Richard Russell wrote:
Wed Sep 19, 2018 9:59 pm
When you say "crashes" can you confirm that you're not talking about the D-Bus error referred to in the install.txt file?
The workaround for that bug does not help. Here's the backtrace:

Code: Select all

Thread 1 "bbcsdl" received signal SIGSEGV, Segmentation fault.
0xf603e60a in ?? () from /usr/lib32/dri/i965_dri.so
(gdb) bt
#0  0xf603e60a in ?? () from /usr/lib32/dri/i965_dri.so
#1  0xf603e8ae in ?? () from /usr/lib32/dri/i965_dri.so
#2  0xf6040365 in ?? () from /usr/lib32/dri/i965_dri.so
#3  0xf60780de in ?? () from /usr/lib32/dri/i965_dri.so
#4  0xf6069e44 in ?? () from /usr/lib32/dri/i965_dri.so
#5  0xf61272c0 in ?? () from /usr/lib32/dri/i965_dri.so
#6  0xf613848b in ?? () from /usr/lib32/dri/i965_dri.so
#7  0xf61397c5 in ?? () from /usr/lib32/dri/i965_dri.so
#8  0xf5b87081 in ?? () from /usr/lib32/dri/i965_dri.so
#9  0xf5bc057d in ?? () from /usr/lib32/dri/i965_dri.so
#10 0xf5bbb541 in ?? () from /usr/lib32/dri/i965_dri.so
#11 0xf5cc53ae in ?? () from /usr/lib32/dri/i965_dri.so
#12 0xf5bc38aa in ?? () from /usr/lib32/dri/i965_dri.so
#13 0xf5cc6ae7 in ?? () from /usr/lib32/dri/i965_dri.so
#14 0xf5cc6e79 in ?? () from /usr/lib32/dri/i965_dri.so
#15 0xf7e55ddc in ?? () from /usr/lib32/libSDL2-2.0.so.0
#16 0xf7e534f9 in ?? () from /usr/lib32/libSDL2-2.0.so.0
#17 0x565683b1 in error ()
#18 0x5677d040 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Thu Sep 20, 2018 5:52 pm

Coeus wrote:
Thu Sep 20, 2018 5:20 pm
The workaround for that bug does not help.
I'm really confused now. You are definitely receiving this error message: "arguments to dbus_message_new_method_call() were incorrect", is that right? And the workaround for that bug given at the SDL forum isn't helping? The confusing thing is that you showed a SIGSEGV fault which, at first sight, is unrelated to the Dbus error.

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Thu Sep 20, 2018 5:59 pm

bakoulis wrote:
Thu Sep 20, 2018 8:19 am
I suspect the problem is from use of bbasmb_x86_64 assembler inside makefile.
But it shouldn't be used! I've added code to the makefile (which Google found) that tests whether your platform is 32 or 64-bits and assembles the appropriate file. If your system is 32-bits, which I think you said it was, the file that it should be assembling is bbdata_x86_32.nas not bbdata_x86_64.nas:

Code: Select all

ifeq ($(LBITS),64)
bbdata.o: ../../src/bbdata_x86_64.nas
	nasm -f elf64 -s ../../src/bbdata_x86_64.nas -o bbdata.o
else
bbdata.o: ../../src/bbdata_x86_32.nas
	nasm -f elf32 -s ../../src/bbdata_x86_32.nas -o bbdata.o
endif
Last edited by Richard Russell on Thu Sep 20, 2018 6:19 pm, edited 1 time in total.

Coeus
Posts: 1079
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Request for help in organising/releasing source code

Post by Coeus » Thu Sep 20, 2018 6:29 pm

Richard Russell wrote:
Thu Sep 20, 2018 5:52 pm
I'm really confused now. You are definitely receiving this error message: "arguments to dbus_message_new_method_call() were incorrect", is that right?
No I do not receive that error message and yes, I believe this is a completely different issue. Upon starting bbcsdl the "Choose IDE" window appears briefly, with no content, and then, if not running under gdb, the shell reports: "Segmentation fault (core dumped)". With gdb I can obviously ask for a stack trace but as neither bbcsdl, the SDL library, or the i965 driver are compiled with debugging symbols it isn't that helpful.

If I build both SDL and lib32-mesa with debugging symbols I get:

Code: Select all

Thread 1 "bbcsdl" received signal SIGSEGV, Segmentation fault.
0xf603d60a in brw_inst_set_bits (value=<optimized out>, low=25, high=25, 
    inst=0x56959b78) at ../mesa-18.2.0/src/intel/compiler/brw_inst.h:1001
1001	../mesa-18.2.0/src/intel/compiler/brw_inst.h: No such file or directory.
(gdb) bt
#0  0xf603d60a in brw_inst_set_bits (value=<optimized out>, low=25, high=25, 
    inst=0x56959b78) at ../mesa-18.2.0/src/intel/compiler/brw_inst.h:1001
#1  brw_inst_set_flag_subreg_nr (devinfo=<optimized out>, 
    value=<optimized out>, inst=0x56959b78)
    at ../mesa-18.2.0/src/intel/compiler/brw_inst.h:173
#2  brw_inst_set_state (state=0x5695508c, insn=0x56959b78, 
    devinfo=<optimized out>)
    at ../mesa-18.2.0/src/intel/compiler/brw_eu_emit.c:543
#3  brw_next_insn (p=0x56955078, opcode=64)
    at ../mesa-18.2.0/src/intel/compiler/brw_eu_emit.c:571
#4  0xf603d8ae in brw_alu2 (p=p@entry=0x56955078, opcode=opcode@entry=64, 
    dest=..., src0=..., src1=...)
    at ../mesa-18.2.0/src/intel/compiler/brw_eu_emit.c:594
#5  0xf603f365 in brw_ADD (p=0x56955078, dest=..., src0=..., src1=...)
    at ../mesa-18.2.0/src/intel/compiler/brw_eu_emit.c:969
#6  0xf60770de in fs_generator::generate_code (this=0xffffb10c, 
    cfg=0x5691c968, dispatch_width=8)
    at ../mesa-18.2.0/src/intel/compiler/brw_fs_generator.cpp:1865
#7  0xf6068e44 in brw_compile_fs (compiler=<optimized out>, 
    log_data=<optimized out>, mem_ctx=<optimized out>, key=<optimized out>, 
    prog_data=<optimized out>, src_shader=<optimized out>, 
    prog=<optimized out>, shader_time_index8=<optimized out>, 
    shader_time_index16=<optimized out>, shader_time_index32=<optimized out>, 
--Type <RET> for more, q to quit, c to continue without paging--
    allow_spilling=<optimized out>, use_rep_send=<optimized out>, 
    vue_map=<optimized out>, error_str=<optimized out>)
    at ../mesa-18.2.0/src/intel/compiler/brw_fs.cpp:7245
#8  0xf61262c0 in blorp_compile_fs (blorp=<optimized out>, 
    mem_ctx=<optimized out>, nir=0x565dfa28, wm_key=<optimized out>, 
    use_repclear=<optimized out>, wm_prog_data=<optimized out>)
    at ../mesa-18.2.0/src/intel/blorp/blorp.c:206
#9  0xf613748b in brw_blorp_get_blit_kernel (prog_key=0xffffc9f4, 
    params=<optimized out>, blorp=0x5661a180)
    at ../mesa-18.2.0/src/intel/blorp/blorp_blit.c:1453
#10 try_blorp_blit (coords=0xffffc04c, wm_prog_key=0xffffc9f4, 
    params=0xffffc35c, batch=0xffffd0c4)
    at ../mesa-18.2.0/src/intel/blorp/blorp_blit.c:2039
#11 do_blorp_blit (batch=batch@entry=0xffffd0c4, 
    orig_params=orig_params@entry=0xffffca5c, 
    wm_prog_key=wm_prog_key@entry=0xffffc9f4, orig=0xffffc9ac)
    at ../mesa-18.2.0/src/intel/blorp/blorp_blit.c:2181
#12 0xf61387c5 in blorp_copy (batch=0xffffd0c4, src_surf=0xffffd0d0, 
    src_level=0, src_layer=0, dst_surf=0xffffd124, dst_level=0, dst_layer=0, 
    src_x=<optimized out>, src_y=<optimized out>, dst_x=<optimized out>, 
    dst_y=<optimized out>, src_width=<optimized out>, 
    src_height=<optimized out>)
    at ../mesa-18.2.0/src/intel/blorp/blorp_blit.c:2654
--Type <RET> for more, q to quit, c to continue without paging--
#13 0xf5b86081 in brw_blorp_copy_miptrees (brw=0x5660cc58, src_mt=0x56602a20, 
    src_level=<optimized out>, src_layer=0, dst_mt=0x569130d0, 
    dst_level=<optimized out>, dst_layer=0, src_x=0, src_y=0, dst_x=0, 
    dst_y=0, src_width=540, src_height=439)
    at ../mesa-18.2.0/src/mesa/drivers/dri/i965/brw_blorp.c:517
#14 0xf5bbf57d in intel_miptree_map_blit (slice=0, level=0, map=0x5691c380, 
    mt=0x56602a20, brw=0x5660cc58)
    at ../mesa-18.2.0/src/mesa/drivers/dri/i965/intel_mipmap_tree.c:3104
#15 intel_miptree_map (brw=0x5660cc58, mt=0x56602a20, level=0, slice=0, x=0, 
    y=0, w=540, h=439, mode=1, out_ptr=0xffffd2a0, out_stride=0xffffd2a4)
    at ../mesa-18.2.0/src/mesa/drivers/dri/i965/intel_mipmap_tree.c:3626
#16 0xf5bba541 in intel_map_renderbuffer (ctx=0x5660cc58, rb=0x56602430, x=0, 
    y=<optimized out>, w=540, h=439, mode=1, out_map=0xffffd340, 
    out_stride=0xffffd33c, flip_y=true)
    at ../mesa-18.2.0/src/mesa/drivers/dri/i965/intel_fbo.c:170
#17 0xf5cc43ae in read_rgba_pixels (packing=0xffffd458, pixels=0xe2a59010, 
    type=33639, format=32993, height=439, width=540, y=0, x=0, ctx=0x5660cc58)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:464
#18 _mesa_readpixels (ctx=0x5660cc58, x=0, y=0, width=540, height=439, 
    format=32993, type=33639, packing=0xffffd458, pixels=0xe2a59010)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:896
#19 0xf5bc28aa in intelReadPixels (ctx=0x5660cc58, x=0, y=0, width=540, 
    height=439, format=32993, type=33639, pack=0xffffd458, pixels=0xe2a59010)
--Type <RET> for more, q to quit, c to continue without paging--
    at ../mesa-18.2.0/src/mesa/drivers/dri/i965/intel_pixel_read.c:296
#20 0xf5cc5ae7 in read_pixels (no_error=false, pixels=0xe2a59010, 
    bufSize=2147483647, type=33639, format=32993, height=<optimized out>, 
    width=<optimized out>, y=<optimized out>, x=<optimized out>)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:1136
#21 _mesa_ReadnPixelsARB (x=0, y=0, width=540, height=439, format=32993, 
    type=33639, bufSize=2147483647, pixels=0xe2a59010)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:1153
#22 0xf5cc5e79 in _mesa_ReadPixels (x=0, y=0, width=540, height=439, 
    format=32993, type=33639, pixels=0xe2a59010)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:1168
#23 0xf7e54ddc in ?? () from /usr/lib32/libSDL2-2.0.so.0
#24 0xf7e524f9 in ?? () from /usr/lib32/libSDL2-2.0.so.0
#25 0x565683b1 in error ()
#26 0x5678eee0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) 
Still no reporting of which function in the SDL library!
Last edited by Coeus on Thu Sep 20, 2018 7:10 pm, edited 2 times in total.

User avatar
Richard Russell
Posts: 527
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Thu Sep 20, 2018 7:14 pm

Coeus wrote:
Thu Sep 20, 2018 6:29 pm
No I do not receive that error message
OK, I was confused by your comment "The workaround for that bug does not help" because it seemed to imply you were.
With gdb I can obviously ask for a stack trace but as neither bbcsdl, the SDL library, or the i965 driver are compiled with debugging symbols
You can easily compile BBCSDL with symbols if you want to, it's your choice. But the stack trace seemed to imply it is crashing in 'i965_dri.so' which according to Google is something to do with mesa. If I've understood you correctly it's a 64-bit system on which the 64-bit build of BBCSDL runs but the 32-bit build doesn't, despite the i386 architecture being installed. Given that 32-bit BBCSDL runs correctly on Android and the Raspberry Pi (and here on 32-bit Ubuntu) it seems unlikely that the fault is in my code.

Coeus
Posts: 1079
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Request for help in organising/releasing source code

Post by Coeus » Thu Sep 20, 2018 8:22 pm

Richard Russell wrote:
Thu Sep 20, 2018 7:14 pm
You can easily compile BBCSDL with symbols if you want to, it's your choice....
It seems in the last trace compiling with debug symbols didn't do anything for libSDL because I needed to rebuild libSDL2 instead. This makes the last few lines:

Code: Select all

#22 0xf5cb9e79 in _mesa_ReadPixels (x=0, y=0, width=540, height=439, 
    format=32993, type=33639, pixels=0xe2a59010)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:1168
#23 0xf7e53cac in GL_RenderReadPixels (renderer=0x567c5ef0, rect=0xffffd5a8, 
    pixel_format=390076419, pixels=0xe2b41046, pitch=1624)
    at /usr/src/debug/SDL2-2.0.8/src/render/opengl/SDL_render_gl.c:1539
#24 0xf7e513c9 in SDL_RenderReadPixels_REAL (renderer=0x567c5ef0, 
    rect=0xffffd61c, format=390076419, pixels=0xe2b41046, pitch=1624)
    at /usr/src/debug/SDL2-2.0.8/src/render/SDL_render.c:2017
#25 0x565683b1 in error ()
#26 0x567c5ef0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
If I try it on a machine with Radeon rather than Intel graphics I instead get an error "Unable to initialise UDEV" in a dialogue box.

Post Reply